Boost logo

Boost :

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

"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, gregod at, cpdaniel at, john at