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

From: Guillaume Melquiond (guillaume.melquiond_at_[hidden])
Date: 2006-05-15 08:30:57

Le lundi 15 mai 2006 à 10:47 +0100, Paul A Bristow a écrit :
> 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(),
> 
> Is the same for ALL FP types (including UDTs) and layouts.

Just a few comments from the IEEE-754 point of view (I know that the C++
standard is supposed to accommodate a wider arithmetic than just
IEEE-754, but still). The revision of the IEEE-754 standard happens to
contain a paragraph on representing infinities and NaN. There still are
motions on this paragraph and the situation should get clearer by the
end of the week.

As it stands, the paragraph mainly says that representing infinities and
NaN is language-defined. Some additions are being considered though.
First the case should not matter, so inf or Inf or INF should not make a
difference (but what case means is not clear). Second, any outputted
value should be inputted correspondingly. In particular, writing a
payload after NaN is allowed, e.g. the C99 syntax "nan(payload)", and
hence it should be parsed till the right parenthesis. It would be a bit
annoying if C++ was not able to read back C99 values.

Finally, the sign of a NaN is not part of its payload: the way it is
computed or propagated is explicitly left undefined. As a consequence, I
don't think there is much point in displaying plus or minus before NaN
since it could have a "random" value.

Best regards,

Guillaume