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

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-05-15 11:27:59

Paul A Bristow wrote:
>> Jeff Garland proposed a solution the problem of serialization of NaN
>> and infinity which had beed discussed
>>
>> http://article.gmane.org/gmane.comp.lib.boost.devel/141006/match=langer+nan
>>
>> Although this is probably the right expendient solution which could
>> be done now (if anyone has the time and skill - SoC?), I also feel
>> this is a general problem that needs a Standard solution (some
>> impect on lexical_cast) so I have drafted a proposal for TR2 which
>> is attached for comment.
>>
>> Briefly, it is a KISS solution.
>>
>> All infinities are output (and input) as one string like "Inf",
>>
>> And all the various NaNs are also a single string "NaN",
>>
>> And on input you get the numeric_limits<FPtype>::quiet_NaN() or
>> infinity(),

As far as I'm concerned it not simple enough.  Once you admit Inf
then someone is going to insist on -Inf (rightly so in my opinion).

The whole idea of trying to overload a floating point number with
non-floating pointing values is the idea that has to go.  I'm sure
someone is going to chime in that this has legitimate uses but it
causes lots of problems.  I'm sure its the source of a lot of
software bugs.  So I would propose only one thing other than
a float - a NaN.

Actually, taking the idea to its logical conclusion, the best would
be just to say that serialization of a NaN is undefined. The
serialization library could implement this by trapping all attempts
to serialize a NaN() as errors.  If a user wants to save/load
other stuff he could define a "rich float" which would parse
the float into a flag + an optional floating point value.  This
would "reduce" the problem to making a portable implementation
of "rich float" which your proposal would address.  I doubt
your proposal will be acceptable though.  Those who think
overloading floats with non-numeric indicators is a good idea
will want more not less variety on the types.  If the "rich float"
were to be implemented, people would want to start adding
their own overloads - like special indicators for pi and e .

I think we should go in the opposite direction.  A float is a
a legitmate floating point value.  A union of float and some
other special non-floating point values is something else.

Robert Ramey