Re: The current proposal
Guillaume,
In my opinion, policy-based design is FAR too heavy weight for the standard
we are considering. This is not a language standard.
Ideally, much of our standard will be implemented in hardware. I share the
desire of Professor Kulisch that it be in hardware, although I do not share
his view that the standard should require hardware. If hardware
implementation is a goal, policy-based design is too much.
Whatever we do must be SIMPLE to understand, to implement, and to use.
Unfortunately, those three sometimes conflict.
Yes, of course it must first be correct.
Dr. George F. Corliss
Electrical & Computer Engineering
Haggerty Engineering #296
Marquette University
P.O. Box 1881
1515 W. Wisconsin Ave.
Milwaukee WI 53201-1881
George.Corliss@xxxxxxxxxxxxx
414-288-6599; -288-4400 (GasDay); -288-5579 (Fax)
Www.eng.mu.edu/corlissg
On 2/23/09 4:13 AM, "Guillaume Melquiond" <guillaume.melquiond@xxxxxxxx>
wrote:
> Le lundi 23 février 2009 à 02:56 -0100, Siegfried M. Rump a écrit :
>
>> (4) xx=interval(x) implies xx.inf==xx.sup.
>>
>> This is also nice property and an argument against
>> interval(Infinity)=[realmax,Infinity].
>
> This property may be a bit too strong. It is usually enough to have
> interval(x) == interval(x,x) only when x is a finite number (and with a
> number type compatible with the interval type, but that was implicit).
>
> So the weakened property does not tell us much what interval(Inf) should
> be. [Max,Inf] is fine with me. As a matter of fact, it's one of the
> input policies (INPUT_INF_BIGREAL) we have implemented in our rewrite of
> the Boost library.
>
> This policy raised a few questions though. Indeed, its purpose was to
> allow the user to perform some floating-point computations before or in
> parallel to some interval computations (e.g. preconditioning interval
> systems). These operations could overflow and we wanted this overflow to
> be innocuous.
>
> And so the question becomes: Why choosing [Max,Inf]? Why not [0,Inf]? Or
> [-Inf,Inf]? Or even [Max,Max]? Which interval actually captures the fact
> that the input has overflown? I mean, due to the overflow, the
> meaningful input may actually be negative (suppose it would have been if
> the exponent range had been more extended) and yet we replace it with a
> positive interval. This is a recipe for a numerical disaster.
>
> So, just to make it clear, my current opinion is: [Max,Inf] is one of
> the best output for interval(Inf), but that doesn't make it a good
> output unfortunately.
>
> Perhaps the solution is just to follow a policy-based design: Provide
> several conversions, some returning [Max,Inf], others returning
> empty/invalid/whatever, and let the user choose which conversion
> actually fits the algorithm.
>
> Best regards,
>
> Guillaume
>