Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk