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 because 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