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

From: Sylvain Pion (pion_at_[hidden])
Date: 2002-09-05 12:33:26

On Thu, Sep 05, 2002 at 11:38:54AM +0200, Gabriel Dos Reis wrote:
> | But anyway, I completely agree that it's not complete, and I would like to
> | find a scheme to improve this.  You may have some helpful comments on this.
> 
> Well, my feeling is that requiring IEEE-754 is too strong for no
> practical benefits for the thing you want to accomplish.  You might
> want to consider that C++ tends to support LIA-1 (and not IEEE-754,
> not this one is not excluded).  It is my belief that any useful
> numerical component for C++ should try to work within LIA-1
> assumptions and not require more unless there are good reasons to do
> so.  In this specific case, I don't see any reason to require more
> than LIA-1.

Note that you are going to be definitely sub-optimal for the rest of the IA
package (the rounded arithmetic operations) if you restrict yourself to LIA-1.

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.

Note that I may be wrong since I got familiar with LIA-1 only this morning.

> | 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.
Hence this information is basically useless to me.

> 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.
The Rounding_policy has a force_rounding thing for Intel processors to fix this
issue for example.

> | Now the question is : what do we do when numeric_limits<float>::digits is
> | different ? 
> 
> The question may be reformulated as follows:  in the case digits ==
> 24, how did you get the above value?

I took the exact binary version of the lower bound of PI for digits==24 which
we had already (any double approximation of PI will be enough to give them to
you, else ask Maple or any multiprecision PI version).
Then I asked Maple to print me this value in decimal with sufficient precision,
so that I get the exact same value, but encoded in decimal.

And that one is guaranteed by the standard (assuming the radix=2 digits>=24)
to be exactly representable, hence no rounding problem here.

> | 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 repeat my constraints (basically, I only want the optimal solution) :
- I want the _best_ (smallest interval) lower and upper bounds on PI for any
  type {float, double, long double}.
- I want them as compile time constants to allow constant propagation
  (otherwise it's too easy :).

I can use whatever program to pre-generate this source code.  My question is
still : what should be the best form to present them to the compiler, so that
the 2 conditions above are met ?

I do not see any cleaner solution that what I proposed before.
If I want to allow radix > 2, the only thing I see is to add other "switches"
based on numeric_limits<>::radix.

I would be happy if there existed a cleaner solution.  Do you see one ?

-- 
Sylvain