Re: [boost] Stream input and output of NaN and infinity

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-05-17 01:13:22

David Abrahams wrote:
> "Robert Ramey" <ramey_at_[hidden]> writes:

>> c) "The IEEE standard strongly recommends that implementations allow
>> trap handlers to be installed."
>> C++ doesn't permit this.
>
> Incorrect.  C++ absolutely does permit implementations to allow trap
> handlers to be installed.  C++ simply does not require it.

My basis for citing this is page 122 of "The C++ Progamming Language"
by Stroustrup, copyright 2000, reprinted May 2003 with corrections.
It says, "In particular, underflow, overflow and division by zero do not
throw standard exceptions".  If that's wrong, incomplete or out
of date, I would be curious to know about it.  It seems to comport
with my personal experience with C++ numeric operations.  Feel free
to expand upon this.

>> d) "Another ambiguity in most language definitions concerns what
>> happens on overflow, underflow and other exceptions. The IEEE
>> standard precisely specifies the behavior of exceptions, and so
>> languages that use the standard as a model can avoid any ambiguity
>> on this point. "  But C++ doesn't permit exceptions to be thrown in
>> these instances.
>
> Incorrect.  Exceptions can be thrown anywhere that undefined behavior
> is specified.  Overflow, underflow, and divide-by-zero all induce
> undefined behavior.

Hmmm I suppose that any thing can happen when undefined behavior
is specified.  So writing a program that depends upon an undefined
operation yielding a Nan would be a bad idea - wouldn't it?

> b) is just a special case of a).  I will agree that eliminating
> undefined floating point behaviors will make C++ more predictable.

>> Until one of the above (or maybe something else) is done.  There can
>> really be no unambiguous resolution to the problem of passing
>> results from undefined operations from one machine to another.
>
> Of course there can be.  All you need to do is write a specification
> for it that describes what happens in all cases, and it will be
> unambiguous.  If you can do this for ints that have nonportable values
> greater than 32767, you can do it for floats and doubles, too.

Besides writing such a specification, wouldn't C++ vendors have to agree
to implement it?.

>> Obviously, I believe that the adoption of b) above would result in
>> fewer programs with hidden bugs.

> That's almost certainly wrong.  Floating point divide-by-zero is
> almost never due to a program bug.  And you can get the same effects
> when dividing by a nonzero number if the result can't be represented.

The kind of situation I'm thinking of is more like the following.  I've got
a program which among its operations is a matrix inversion.  The program
correctly implements the chosen algorithm.  Now I load a near-singular
matrix and invoke the matrix inversion operation.  The sequence of
operatons results in over/under flows in some intermediate results.  No 
exception
is thrown but some NaN's are propagated through the calculations.  The
final result Matrix may or may not have one or man Nan's.  So now I
have a result that is wrong but do not know it and have no way of knowing
it.

In FORTRAN this was never a problem as the program aborts at the
first overflow/underflow or whatever.

What am I expected to do here?  I could recode the matrix inversion to
check each intermediate result to see if its a NaN?  I can't imagine
that's what I'm expected to do.  How do people handle this now?

Robert Ramey