Re: The current proposal
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