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

From: Sylvain Pion (pion_at_[hidden])
Date: 2002-09-06 18:48:39

On Sat, Sep 07, 2002 at 12:17:44AM +0200, Gabriel Dos Reis wrote:
> | 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.

Good.

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

That's fine.

> | These two issues are almost completely unrelated.
> 
> Agreed.

Good !

> | 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 definitely can have an LIA-1 compliant IA library, it's just a matter of
providing an adequate Rounding_policy.  This is possible, easy.  We agree.
Think just like if it existed, and if I wanted optimized version which rely on
non-standard stuff, OK ?
As I said, the advantage of using the non-standardized (when available of
course, but quite available in practice) features is to have a better
implementation (faster and/or sharper intervals).

Issue #2 is no big problem.

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

Definitely.  I don't strictly _need_ these features.
When I say sub-optimal, I just mean that an implementation using only LIA-1
where you could use dynamic directed roundings, will be slower or less precise
than its possible non-LIA-1 counterpart.

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

Yep.  But what should be these constants to avoid the problem I mentioned in
the reply to Herve ?  My point is that they have to be (exactly) representable.
Which makes the damn thing awful (especially since I want a header working
correctly with a good deal of platforms) !  So I'd like the simplest solution.

> | >   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 ;-).

Sorry that I'm not clear enough.

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

I brought the rounding issue because it's the mention of rounding in 2.13.3.1
which is the problem.  It's not the round_style (you brought that in I think),
nor the dynamic rounding in IEEE.

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

Well, you know, for the IEEE features that are used, we usually use some inline
asm to access them anywa, because it's faster than the C functions...
So at that point, nothing is portable.

I'm fine with providing an LIA-1 only portable version, together with the
useful optimized code aside.

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

Actually, the dream solution would be to modify the "floating-literals" grammar
in the standard, so that we can specify one of the four usual rounding modes,
for each constant that we give.
This could be done by adding an additionnal floating-suffix in [nNzZpPmM]
(similar to the current [lLfF]).

That would be _really_ wonderful.
That would be _the_ nice solution for issue #1.

But it's not C++.

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

Yep, but not as obvious as that : the output constant must be representable in
the target FP type.  So no clean solution, and so my request for an easier one.
See the other mail.

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

Yep.  "algorithm" was a big word for the compile-time thing, but I wanted to
point out by using that term that it's not just a matter of putting the easy
"a decimal string with enough precision".
It still has to be painful and full of ?: (or integer template stuff as
proposed by Herve, but it's a detail at that point, the most painful stuff
remains).

-- 
Sylvain