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

From: John Maddock (john_at_[hidden])
Date: 2006-05-16 05:47:20

Robert Ramey wrote:
>> 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.

The usual use case is this: suppose you have an algorithm with a 
"fast-but-possibly-fagile" implementation, and a "slow-but-never-brakes" 
implementation.  It's reasonably common to try the "fast" version first and 
then revert to the slow-and-possibly-inaccurate-but-stable version only if 
you need to: because you get an infinity or NaN from the "fast" version for 
example.  Sometimes the difference in performance between the two is *huge*, 
and if the fallback version has to resort to using logs for calculation 
(just as one example), then it may be much less accurate, as well as slower.

Now I admit, that personally I've never *quite* needed to serialise 
intermediate results of calculations, but I've come close a few times, and 
for very long running algorithms I can certainly see the need for 
checkpointing / save and restore, so that programs can be stopped and 
started without returning to the starting post every time.  Think large 
scale monti-carlo simulations for example, or even distributed applications 
like SETI_at_home, and it's drug-discovery copycat's.

Currently the problem with serialising NaN's and Infinities, not to mention 
the regular stream IO bug that's been discussed around here, makes this far 
more error prone than it should be.

In other words there is a problem looking for a solution here: that doesn't 
mean that you should be expected to just go off and solve it based on 
someone's whim, but the problem does need looking at and addressing by 
someone nonetheless.

John.