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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk