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

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-05-16 02:18:08

Jeff Garland wrote:
> 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.

In my view, your usage above is logically and functionally equivalent
to something like

class dt {
    enum { a, b, c } state;
    int value;
};

Since value can be of different "types" it pretty equivalent to a C union.
The fact that its not an C union is really just an implementation detail.
I'm using the word union as a short hand for all these types of
constructions.  Used in this way the current float behavior is a
union.  Perhaps a better word would have been "multi-type"
of which the C union would be an example.

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

That's how math works - I think C++ should work the same way.

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

Not in any portable way. Page 132 of my reference "The C++
Programming Language" by Stroustrup says "the effect of
dividing by zero is undefined but doing so usually causes abrupt
termination of the program."  In fact, when running under the
debugger, my VC++ IDE permits me to trap or ignore and
continue when this occurs.  Intel chips have a floating point
unit which throws a hardware exception when this occurs.  C++
is designed to not handle these cases.  I don't know what
other processors do - I suppose it varies.  In any case - its
undefined.

>> BTW - as far as the serialization system is concerned ...
>
> I think the whole thing that started this thread is to fix the
> standard so that these values can be correctly and portably serialized.

I only mentioned it because someone expressed the notion that
this is only a problem for serialization.  I don't think its a serialization
problem.  I think its a problem which manifests itself when
one tries to implement serialization - among other places.

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

Well, of course that's true if one believes that NaNs and +/-Inf, +/-0 etc 
have
legitimate uses.  But I'm not convinced.

> We need to help Paul fix the standard, it just isn't that difficult a 
> problem...

I'll bet that given the variety of handling things now - it will be a lot 
more difficult
than it first appears.

Robert Ramey