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
> I suppose that's possible. I'm not familiar with such applications.
> It sounds to me that they would be implemented in special hardware
> 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
>> 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.
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 of undefined type?
-- 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