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

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-05-15 22:43:07

Martin Bonner wrote:
> -----Original Message-----
> Robert Ramey wrote:
>
>> Peter Dimov wrote:
>>
>>> It depends. Where do you draw the line? Is inf a number? Is -0.0 a
>>> number? You have to have NaN if you want to be able to represent x/y
>>> as a float.
>
>> That's the problem.  x/y is not a valid operation if y is equal to
>> 0. So
>> it can't be represented as a number.
>
>> The fact that C++ permits such an operation makes C++ different
>> than arithmetic.
> "different than SOME arithmetics".  The arithmentic C++ (well,
> actually IEEE) defines is a perfectly sensible arithmetic.
>
>> The fact that C++ uses operators like "/" and defines them
>> similar to - but not identical to - the way they are defined by
>> standard arithmetic
>
> Granted.  It isn't the standard arithmetic.
>
>> is the source of all these problems.
> What problems?  (Apart from the extra work involved for authors of
> libraries like serialization I mean!)

suppose that z = x * y generates a Nan or +Inf or whatever one some
machine for some x and y.  Now z contains an undefined value which
is used on some other operations which presumably result in other
types of Nan's.  This behavior has the following problems:

a) its undefined
b) it varies from machine to machine.  On some machines the hardware
will trap an abort the program as it won't throw a C++ exception.
Other machines will store some variety of Nan in the result
c) if it doesn't trap we're just massaging undefined values.
d) we're getting some useless result but don't know it untill maybe
later or many never.

How can any "real program" find this useful?  How can such a program
not be "broken".  I suppose there might be some case where its OK
but they would have to be special in some way.

>> I say that C++ should be changed to so that the floats and operators
>> which apply to them should implement what people expect from
>> arithmetic operators.

> Yes, but realistically that is never going to happen.

LOL - it seems you're right there.  But that is not my point here.

> Wouldn't it be better to support the use-cases that people have in
> real code?

well that's what we have to do.  But it raises the issue of whether
its worth spending time to support programs that are most likely
broken in any case.

Robert Ramey