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

From: David Abrahams (dave_at_[hidden])
Date: 2006-05-16 08:46:55

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

> David Abrahams wrote:
>> 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.
>
> I suppose that's possible. I'm not familiar with such applications.

Exactly.

> It sounds to me that they would be implemented in special hardware

No.

> and sort of out of the C++ mainstream.

Wow, that's exactly the kind of thing politicians say about each other
when they want to paint their views as radical and worthy of
dismissal.

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

It's currently visible, since it is possible to test for NaN.  And as
far as I know, it's modifiable.  What, exactly, do you mean by
"modifiable?"  I can explicitly request a NaN from numeric_limits.

>>> I would argue that such code is already broken anyway - it just
>>> looks like its working.
>
>> Really, you still think so?
>
> My view on this is in another post.
>
>> If so, I'd like to know how you measure "brokenness."
>
> A program which produces an undefined result is "broke"

I think what you mean to say is that it's nonportable.

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

That doesn't mean there's no way to do it.  I can think of any number
of ways, including, for example, having a replaceable handler for
translating unrepresentable values.

> Its even worse, there is way to write portable code which will
> generate any specific one of the "undefined" types.  

  numeric_limits<float>::quiet_NaN()

Is "reasonably portable."

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

Type of undefined type?

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