Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2006-05-15 15:01:44


"Robert Ramey" <ramey_at_[hidden]> writes:

> David Abrahams wrote:
>> "Robert Ramey" <ramey_at_[hidden]> writes:
>>
>>> I think we should go in the opposite direction. A float is a
>>> a legitmate floating point value. A union of float and some
>>> other special non-floating point values is something else.
>>
>> Notwithstanding the fact that NaN is "not a number," it is a
>> legitimate floating-point value, i.e. a legitimate value for the type
>> float.
>
> I guess it depends what one means by "legitimate". It is
> is certainly "legal" in C++ - no question about that fact.
> Its certainly not a number - no question about that either.
> The problem is that C++ makes float a union of two
> different things

Not any more than a pointer is a "union of two different things."
There are quite a few operations on pointers that suddenly become
verboten when the pointer is null, and even more such operations when
the pointer is dangling.

> and that is what creates all the problems we have with it. C++
> should correct this by making the result of arithmetic operations
> which result in Nan's either undefined or throw exceptions. Oh I
> know that this would break a lot of existing code.

Not only break, but break unfixably. There are important numerical
applications where large collections of individual floating values
(e.g. vectors and matrices) have to be computed in parallel, and one
or more NaNs in the result do not render the whole calculation
useless.

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.

> I would argue that such code is already broken anyway - it just
> looks like its working.

Really, you still think so? If so, I'd like to know how you measure
"brokenness."

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

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