| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of | Guillaume Melquiond | Sent: 15 May 2006 13:31 | To: boost@lists.boost.org | Subject: Re: [boost] Stream input and output of NaN and infinity | | 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 been discussed | > | > | http://article.gmane.org/gmane.comp.lib.boost.devel/141006/ma | tch=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. Thanks for this helpful, and much more informed that I am, comment. Does this mean that the // C99 macros defined as C++ templates template<class T> bool signbit(T x); is undefined for a NaN? I note that ISO/IEC 9899:1999 (E) 7.19.6.1p8: "A double argument representing an infinity is converted in one of the styles [-]inf or [-]infinity - which style is implementation-defined. A double argument representing a NaN is converted in one of the styles [-]nan or [-]nan(n-char-sequence) Explicitly allows a preceeding - sign. Seems like it is hard to justify prohibiting the - sign - but clearly its meaning is 'implementation defined'? Similarly interpretation of the suffix (n-char-sequence) is too - but how is the stream expected to know when it has ended? This sounds excessively complicated for little gain in serialization when the real need is just to indicate a 'bad' number or a 'missing' number - being able to differeniate these two would be much more useful. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS