From: Gabriel Dos Reis (gdr_at_[hidden])
Date: 2002-09-06 17:17:44
Sylvain Pion <pion_at_[hidden]> writes:
| The first issue #1 is how to create the compile-time 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 LIA-1/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 IEEE-754. Therefore, when you're mentioning IEEE/C you
should be very careful about the exact non-standard features you're
| These two issues are almost completely unrelated.
| 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 LIA-1
| (which could easily be provided as a Rounding_policy class), based on
| rnd_epsilon for example.
Actually, if you're able to use non-standard features to implement the
approximations, then you should have -no- trouble to use only LIA-1
constraints where appropriate, increasing the portability of the library.
| I still claim it would be sub-optimal wrt what can be
| done in hardware if you allow access to dynamic rounding modes available with
But then you don't need full IEEE-754. 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 compile-time 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 input-output) for tacking that task.
A helper script/program takes as input the target FP system description
and output the constants at configuration time.
| > 2) LIA-1 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.
| LIA-1 only knows about a fixed, static, rounding mode anyway, so out for #2.
But then IEEE-754 is not part of C++ :-). And even if you require
IEEE-754, 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 LIA-1 only (i.e. no dynamic
| rounding modes) if you can access IEEE is usually sub-optimal in sharpness of
| the intervals, as well as probably in performance.
My point is that if you really want to require non-standard features,
just require those, minimal in numbers, sufficient for building the
library. You get increased portability. Do you really need *full*
IEEE-754 (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 compile-time constant.
| So, always my original question : how do I generate my compile-time 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 COMPILE-TIME constants, I need a
| COMPILE-TIME algorithm.
No, you don't need a compile-time algorithm. You just need a way to
have those constants generated at compile-time. 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk