
Boost : 
From: Gabriel Dos Reis (gdr_at_[hidden])
Date: 20020906 17:17:44
Sylvain Pion <pion_at_[hidden]> writes:
 The first issue #1 is how to create the compiletime constants for the best
 lower and upper bounds of PI for the float, double, long double.
This I fully understood.
 The second issue #2 is the dynamic rounding mode usage (which are not available
 in LIA1/C++ but in IEEE/C), used at run time (by almost all current
 Rounding_policy classes) in the IA library to do its computations.
This also I fully understood, as seperate from issue #1.
I never tried to confuse them.
You should note that the "C" part in C++ (aka C90) doesn't know
anything about IEEE754. Therefore, when you're mentioning IEEE/C you
should be very careful about the exact nonstandard features you're
talking about.
 These two issues are almost completely unrelated.
Agreed.
 This is actually the first issue that worries me the most here (the original
 one that I mentionned).

 For the second issue, I definitely can see an implementation using only LIA1
 (which could easily be provided as a Rounding_policy class), based on
 rnd_epsilon for example.
Actually, if you're able to use nonstandard features to implement the
approximations, then you should have no trouble to use only LIA1
constraints where appropriate, increasing the portability of the library.
 I still claim it would be suboptimal wrt what can be
 done in hardware if you allow access to dynamic rounding modes available with
 IEEE
But then you don't need full IEEE754. You just need ways to access
dynamic rounding modes. And the absence of such features does not
defeat the library suboptimal!
 Now for the first issue, the question is not related to dynamic rounding modes
 at all, since I want to generate compiletime constants. The question is how
 to generate them. They have to be correct (lower bound <= PI, and upper bound
 >= PI) up to the last digit, and if possible (it's kind of important, hence I
 add this in my constraits), be the best bounds for PI with a given FP type.
Algorithms are know to compute digits for PI up to arbitrary
precision. The whole issue then reduces to how many digits you would
want to generate given a radix and a precision. There are known
algorithm (used in floating point inputoutput) for tacking that task.
A helper script/program takes as input the target FP system description
and output the constants at configuration time.
[...]
 > 2) LIA1 requires way to detect the rouding styles. C++ defines
 > integral constants expressions to access them.

 Yes, that's fine. I just claim it's basically useless for me for both issues.
I hear all your claims, I'm trying to sort them and find which are
found and which are not ;).
Notice that rounding style was brought up because you said you didn't know
which one is used. So either, that information is really useless for
you then I don't know why you were talking about it in the first place. Or
else it is relevant then I can't understand why you think it is
useless for both issues.
 LIA1 only knows about a fixed, static, rounding mode anyway, so out for #2.
But then IEEE754 is not part of C++ :). And even if you require
IEEE754, several of the functions are just recommanded.
Note also, that if you have an implementation that has
numeric_limits<>::is_iec559 == true, then it is likely that you'll
have access to the recommanded functions.
[...]
 > 3) The above by themselves don't make the think suoptimal for the
 > particular problem at hand.

 For issue #2, I still claim that relying on LIA1 only (i.e. no dynamic
 rounding modes) if you can access IEEE is usually suboptimal in sharpness of
 the intervals, as well as probably in performance.
My point is that if you really want to require nonstandard features,
just require those, minimal in numbers, sufficient for building the
library. You get increased portability. Do you really need *full*
IEEE754 (meaning all of the recommanded functions) or do you just
need a small number of functions. I guess you just need the latter.
[...]
 > 2) the case round_indeterminate represents just 1/5 of all possibilities
 > (assuming they all have the same probaibilities).

 I have to take it into account.
Certainly. I don't say the contrary, Mr Lapalisse neither.
 I doesn't help me to know it.
If you know that the plateform rounding style isn't the one you need,
it helps you know what you can't assume available.
 It would help if I knew that all desired platforms had round_style=nearest.
More accurately, it would be helpful if you could *set* the rounding
style to neearest.
 > 3) round_indeterminate doesn't mean anarchy. It means the rounding
 > style is indeterminable as a compiletime constant.

 Agreed.
 So, always my original question : how do I generate my compiletime constants ?
Take an algorithm that generates the constant PI, take an I/O
formatting algorithm, connect them.
[...]
 You missed _my_ point : I have no problem to using any algorithm to generate
 these constants. BUT, given that I want COMPILETIME constants, I need a
 COMPILETIME algorithm.
No, you don't need a compiletime algorithm. You just need a way to
have those constants generated at compiletime. The difference being
that a separate script/program may generate them at configuration
time. Look, you just did it (in an admitely naive way) with Maple.
[...]
 If you don't agree, please give me your solution.
See above.
 Gaby
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk