Re: [boost] Formal Review for Interval Library- getting intervals of constants

From: Gabriel Dos Reis (gdr_at_[hidden])
Date: 2002-09-06 03:41:31

Sylvain Pion <pion_at_[hidden]> writes:

| For example, changing dynamic rounding modes is not something available in
| standard C++ (it is in ISO C though).
| So we could implement an IA based on LIA-1 only I guess (via a Rounding_policy
| class), using numeric_limits::rnd_epsilon, but that would make the intervals
| larger than necessary (because LIA-1 has no counter part to IEEE's inexact
| flag for once), and/or it would be inefficient.

I think you're misinterpreting something.  

  1) LIA-1 makes conformance to IEEE-754 optional.  In C++, the
     binding is that if in addition of conforming to LIA, an executing
     environnement wants to support IEEE-754, then
     numeric_limits<>::is_iec559 is true.

  2) LIA-1 requires way to detect the rouding styles.  C++ defines
     integral constants expressions to access them.

  3) The above by themselves don't make the think suoptimal for the
     particular problem at hand.

| > | To recall, what I want is the sharpest interval bounds (for float, double,
| > | long double) on PI (other constants might follow, but this one is needed for
| > | the trigonometric functions).
| > | 
| > | As mentionned above, the standard doesn't impose any particular rounding style,
| > | so you can't assume a particular one,
| > 
| > Certainly, however the standard does list the possibilities.  And
| > those are given by integral constant expressions.  So the picture is
| > not that dark.
| 
| It still doesn't help at all in practice : if I want to support platforms with
| round_style=indeterminate I do have to handle the worst, painful case.

Again, I think you're misinterpreting something.  

  1) Obviously if you *want* to support platforms with
     round_style=round_indeterminate, then you're willing to do the
     necessary work to provide the support, i.e. you *want* to do the
     painful case.  So what?

  2) the case round_indeterminate represents just 1/5 of all possibilities
     (assuming they all have the same probaibilities).

  3) round_indeterminate doesn't mean anarchy.  It means the rounding
     style is indeterminable as a compile-time constant.

| > Even more, it makes perfect sense to use greater precision to perform
| > certain computations (with long double) and there you have no IEEE-754
| > rules to backup your assumptions -- no assurance that you have a
| > hidden nit (x86 with intel-extended format has no hidden bit, SPARC
| > has a hidden bit).  
| 
| I am aware of these issues.  Intermediate computations with larger precisions
| than the containing type are a correctness issue for IA.

Well, my point was more about not-well foundness of your IEEE-754
format assumptions.

[...]

| > | Is there a cleaner way to do that ?
| > 
| > Figure out how a good approximate value can be computated as a
| > function of digits, and other parameter.  IMO, that is much more
| > scalable and robust.
| 
| ... and sub-optimal !

I think you missed tmy point.  Obviously, when you asked Maple (or
whatever programs) to give you a number, then print them using a
specified format, the answer was a function of the specified format.
My point is to use the underlying algorithm to generate the constants.
There is nothing sub-optimal in that.

-- Gaby