
Boost : 
From: Sylvain Pion (pion_at_[hidden])
Date: 20020905 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 IEEE754 is too strong for no
> practical benefits for the thing you want to accomplish. You might
> want to consider that C++ tends to support LIA1 (and not IEEE754,
> not this one is not excluded). It is my belief that any useful
> numerical component for C++ should try to work within LIA1
> 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 LIA1.
Note that you are going to be definitely suboptimal for the rest of the IA
package (the rounded arithmetic operations) if you restrict yourself to LIA1.
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 LIA1 only I guess (via a Rounding_policy
class), using numeric_limits::rnd_epsilon, but that would make the intervals
larger than necessary (because LIA1 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 LIA1 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 IEEE754
> rules to backup your assumptions  no assurance that you have a
> hidden nit (x86 with intelextended 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 suboptimal !
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 pregenerate 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk