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