Re: [boost] Formal Review for Interval Library- getting intervals of constants

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
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 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
| IEEE 

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.
| 
| Agreed.
| 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.

See above.

-- Gaby