From: Robert Ramey (ramey_at_[hidden])
Date: 2005-12-01 18:42:09
John Maddock wrote:
>> This will be helpful in serializiing non-number floats and doubles.
>> But there is even a bigger problem. That is, we haven't found
>> a portable way to create all the various flavors of these things.
>> For native binary archives this isn't problem as the orginal
>> bits are recovered. But I can't see how to handle these
>> kinds of floats in portable binary or text based arechives.
> Depends what you want to recover, I'm assuming that norms, denorms and
> zero's are handled OK already?
Actually, I don't know. The issue currently occurs with text/xml archives.
stream output is used to write floats/doubles to he stream. This was based
on the assumption that an input stream could read anything an output
stream from the same library implementation might write. This turns
out not to be the case for at least some standard library implementation.
This was discovered for some library (VC 7.1) I'm not sure whether
a pair of stream implementations are required to beable to do this or
> Infinities should be OK too, and on most platforms
> std::numeric_limits<T>::infinity() will get you want you want (you can
> always negate it as required).
> NaN's are a whole other issue, you should be able to get a NaN from
> numeric_limits<T>::quiet_NaN(), if they're supported, but it won't be
> the same NaN you had originally. However, an interesting property of
> NaN's is that:
> if x is a NaN then:
> x == x
> is *false* under IEEE arithmetic rules, so you can't actually tell
> whether you've got the same NaN back or not anyway!
> The only thing you can tell is the sign of the NaN: according to C99
> you can get the sign of a NaN from signbit, and set the sign of a NaN
> with copysign, but there's no way to portably implement those two :-(
> In any case I'm not sure why anyone would want to care about the sign
> of a NaN.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk