### Tuesday, April 25, 2006

## NaN and floating point exceptions

On the ISE Eiffel mailing list there has been a discussion amongst Chris Saunders, Steven Wurster and others about the behaviour of DOUBLE and other numeric classes when IEEE-754 NaNs are encountered.

Bertrand Meyer wrote:

Thomas Beale and Steven Wurster agreed that the original design was right in choosing mathematical abstraction for the modelling basis, but "what it lacked, as we are now finding out, was classes for concrete models of representation and processing. It seems that these are now being populated with all the INTEGER_16 etc classes". But is inheritance the correct relationship between the computer-math and theoretical-math classes?

Bertrand Meyer posited that...

Incidentally, although IEEE-754 was accepted in 1985, it was not nearly so widely implemented when the Eiffel kernel classes were originally designed as it is now. IEEE-754 currently undergoing revision.

If you aren't au fait with IEEE-754 you may wish to read David Goldberg's article What Every Computer Scientist Should Know about Floating-Point Arithmetic or see the IEEE-754 FAQ.

Bertrand Meyer wrote:

The problem is that while there are well-established axioms for the underlying mathematical sets -- integers, rationals, reals... -- the modeling of their computer counterparts is much less well understood. NUMERIC ... models the mathematical notion of a commutative ring structure. This decision can be criticized but it is explicit and unambiguous.

Bertrand Meyer pointed out that there were two approaches to modeling objects of numeric types: one could either start from the mathematical sets, or start from the actual rules of computer arithmetic. He invited suggestions that took into account "all three aspects -- the mathematics, the software and the hardware".In this context it doesn't particularly shock me that operations on NaN should cause invariant violations. After all, isn't NaN supposed to mean "not a number"? If it's not a number, it doesn't have to satisfy the properties of numbers.

Thomas Beale and Steven Wurster agreed that the original design was right in choosing mathematical abstraction for the modelling basis, but "what it lacked, as we are now finding out, was classes for concrete models of representation and processing. It seems that these are now being populated with all the INTEGER_16 etc classes". But is inheritance the correct relationship between the computer-math and theoretical-math classes?

Bertrand Meyer posited that...

one solution in this direction would be to have a notion of "normal" number, where NaN is not "normal", and rewrite some -- probably most -- postcondition and invariant clauses in the form

(a.normal and b.normal) implies P

Incidentally, although IEEE-754 was accepted in 1985, it was not nearly so widely implemented when the Eiffel kernel classes were originally designed as it is now. IEEE-754 currently undergoing revision.

If you aren't au fait with IEEE-754 you may wish to read David Goldberg's article What Every Computer Scientist Should Know about Floating-Point Arithmetic or see the IEEE-754 FAQ.

Comments:

<< Home

I don't know whether it was pointed out in the discussion on the ISE list, but Gary Leavens has a paper in a recent issue of JOT on the problems posed by NaNs:

http://www.jot.fm/issues/issue_2006_03/column8

Post a Comment
http://www.jot.fm/issues/issue_2006_03/column8

<< Home