
Boost : 
From: Gabriel Dos Reis (gdr_at_[hidden])
Date: 20020906 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 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.
I think you're misinterpreting something.
1) LIA1 makes conformance to IEEE754 optional. In C++, the
binding is that if in addition of conforming to LIA, an executing
environnement wants to support IEEE754, then
numeric_limits<>::is_iec559 is true.
2) LIA1 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 compiletime constant.
 > 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.
Well, my point was more about notwell foundness of your IEEE754
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 suboptimal !
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 suboptimal in that.
 Gaby
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk