Boost logo

Boost :

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.

Robert Ramey

Boost list run by bdawes at, gregod at, cpdaniel at, john at