From: Paul A Bristow (pbristow_at_[hidden])
Date: 2006-05-15 11:22:24
| -----Original Message-----
| From: boost-bounces_at_[hidden]
| [mailto:boost-bounces_at_[hidden]] On Behalf Of
| Guillaume Melquiond
| Sent: 15 May 2006 13:31
| To: boost_at_[hidden]
| 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
| > 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) 126.96.36.199p8:
"A double argument representing an infinity is converted in one of the
[-]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 A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk