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

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-05-16 01:21:45

Robert Ramey wrote:

>> Besides all that, eliminating NaNs from the serialization problem
>> space is really impossible.  Even if we struck them from the C++
>> language, someone would effectively recreate them using
>> optional<float> or the equivalent.
> 
> Actually that would be an improvement in that the "union" would
> be explicit, visible and modifiable.  In fact I could see the utility
> right now of a "safe_float" which would look something like
> 
> #ifndef NDEBUG
> BOOST_STRONG_TYPE(float, safe_float)
> safe_float operator/(safe_float x, safe_float y){
>     if(y < epsilon) // machine dependent epsilon
>         throw overflow_exception
>     return x / y;
> }
> ...
> #else
> #define safe_float float
> #endif

Robert -- I believe that thinking of floats as a "union" is the wrong 
analogy.  In date_time there's -inf, +inf, and not_a_date_time.  There's 
no union internally used to represent them.  These values are extremely 
useful for writing real programs and have obvious mappings into the real 
world -- trust me, I've used them in a real world scheduling system. In 
fact, since date_time uses integers internally the special values are 
simply implemented as a reserved number value.  nadt is essentially 
max_int, +inf == max_int - 1 and -inf == min_int.   I believe you can 
think if floating point number special values in the same way -- 
although the internal implementation may be in hardware ultimately, the 
special values are really just certain bit patterns that are defined to 
represent these logical states.

> A program which produces an undefined result is "broke"

I guess all of 'math' is broken then too?  The only way to deal with 
singularities in math is to effectively 'bail-out' -- say, well don't do 
that.  If you try to do a divide by zero in a program it's the same -- 
some external logic needs to deal with that case.  The fact that the 
floating point type tells you that you divided by zero by giving and 
infinite result is actually a well defined and correct interface.

> BTW - as far as the serialization system is concerned I
> never had a problem with the idea of recovering the exact
> kind of "undefined" data.  Its just that there's no way to
> do it with archives which might be ported from one machine
> to another as there is no guarentee that the reading
> machine has the same set of of undefined results as the
> source machine.  Its even worse, there is way to write
> portable code which will generate any specific one
> of the "undefined" types.  One might hack something
> together that would recover some undefined type
> but it wouldn't be guarenteed to the the same original
> type of undefined type.  So the whole effort would be
> for naught.

I think the whole thing that started this thread is to fix the standard 
so that these values can be correctly and portably serialized.  But it 
seems that we are now distracted from that purpose. In my view, it's 
terribly flawed when a language like JavaScript can correctly serialize 
NaNs and Infinites and C++ can't.  We need to help Paul fix the 
standard, it just isn't that difficult a problem...

Jeff