Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Edge case conversions, exceptions to IEEE FPA

Arnold Neumaier wrote:
We all know that floating point computations can yield arbitrarily wrong results not just if the floating point result is oo. Following the argumentation to convert intval(1e400) to the empty set, you could therefore argue that intval(x) should always return empty... 

Taking into consideration the recent wish that
- an implementation should follow the principle of "least astonishment" and - the amateur programmer should get the expected results 

Even amateur programmers must know that the result will be incorrect for
intval(1e308); once they know that they weon't write intval(1e309)
or intval(1e400).



while the pro should be able to decide,
intval(1e400) = [realmax, oo] seems to be the sensible choice for me.


I find
   intval(1e308) = an interval not containing 1e308
   intval(1e309) = [realmax,inf]
at least astonishing as
   intval(1e308) = an interval not containing 1e308
   intval(1e309) = Empty
especially as the 754 standard permits loaded NaN's which allow the
user to distinguish different sources of NaN, hence different kinds
of Empty.


I am a bit reluctant to rely on a property of IEEE754 NaNs which is new
to me, probably not used a lot, and which may have some portability issues
(I would rather that IEEE-1788 only requires a subset of IEEE-754-2008).

Moreover, and most importantly, I am not sure how nicely this information
gets propagated through operations:
- how does it propagate through a floating-point addition?
 (e.g. what if you add 2 such NaNs with the same or different attached information?)
- how would it then propagate through interval additions and other operations?
 and with which overhead?

If it does not propagate nicely (automatically and efficiently), then basically
it means that the user has to test manually what kind of Empty he gets,
*just after* the conversion float->interval, which is as cumbersome as testing
it *just before*, but the later removes the need for reporting useful information
in the conversion, so IMO it's better.


However, writing intval(1e308) or intval(1e309) must be considered a
semantic error anyway, hence the result doesn't matter, and simplicity and genericity of the definition should be the deciding principle. 

Further thinking about this, I am now of the opinion that
intval(1e309) = Empty  is not safe enough.
Arnold's proposal mentions an accompanying error flag, but also the sentence
"I expect that the flag will never be inspected", with which I agree.

I would definitely prefer it to return Entire.
At least this way, the basic containment property is at the safest level,
while if you use Empty, an error could easily go undetected:

Take the example of an algorithm computing the hull of a bunch of floating-point
values.  The algorithm iterates over the values, converts them to interval,
and accumulates using hull().  If a floating-point value is 1e309 or +Inf,
and it gets converted to Empty, then it has gone unnoticed.

If you use Entire, you will get useless computations, which will force you to
look at the problem, but it will not go unnoticed.

--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature