From: Robert Ramey (ramey_at_[hidden])
Date: 2006-05-16 11:40:02
John Maddock wrote:
> 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.
Actually I can sympathize with this scenario - that was my motivation
for the "safe_float" example.
> 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.
Technically, this isn't a serialization issue. It only comes up there
text based archives use stream IO where the issue crops up. That is,
the problem pops up when one tries to load a NaN of somesort from
a text stream. Stream I/O fails. The serialization system just recognizes
that fact and punts with an exception. So if one wants to address this
the best way would be to fix the underlying stream i/o.
> 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.
No dispute there - the question is what is the correct solution.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk