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

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
|  > 
|  > 
|  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
[phone] & SMS, Mobile [phone] & SMS