
Paul A. Bristow wrote:
-----Original Message----- It sounds reasonable in most cases - however there are situations when a genuine NaN might be required - an example might be where you have a table of statistics, and a NaN is used to indicate "no data".
+1 for NaN - and for infinity
In Boost.Math it has proved very useful to properly support these two types - and they are 'Standard' in numeric_limits.
Johan Rade's facets for Facets for Floating-Point Infinities and NaNs shows that I/O for this can be done - and is portable for all platforms that support them (all the popular ones).
Whereas the layout in 64-bit doubles of IEEE754 layout is pretty standard for X86 and ARM chips, the output of infinity and NaN isn't - but using the above facets it can be fixed.
So I think this is should be the objective for serialization too.
Paul
Here is what I would like to see happen a) Johan Rade's facets for Facets for Floating-Point Infinities and NaNs should get incorporated into boost as a separate library. b) text serialization would incorporate that library. Usage of this facility would be conditioned on an archive attribute flag assigned when the archive is created. This would leave the current behaviour and provide the NaN friendly behavior as an option. c) boost floating point support should be created which handles in a uniform manner floats 8,16, 24, 32, 64, 128 bits long. This should be handled by i/o streams. To make this job easier - only ieee754 format would be supported (of course both endians would be supported). d) floating point support should be added to portable binary archive e) and portable binary archive should become an official part of the boost serialization libary. All the "bits" are "floating" around, never the less putting all this together is a huge project - probably too big even for a master's thesis. But to me it would close a bunch of holes in C++ handling of floating point numbers. Robert Ramey