On 2005-06-23, Tim Peters <[EMAIL PROTECTED]> wrote:
> C89 doesn't define the result of that, but "most" C compilers these
> days will create a negative 0.
>
>> and (double)0x80000000 doesn't work,
I think you meant something like
float f;
*((uint32_t*)&d) = 0xNNNNNNNN;
>> And I don't know how to test for it either, x < 0.0 is not
>> necessarily true for negative 0.
>
> If it's a 754-conforming C compiler, that's necessarily false (+0 and
> -0 compare equal in 754). Picking the bits apart is again the closest
> thing to a portable test. Across platforms with a 754-conforming
> libm, the most portable way is via using atan2(!):
[brain-bending example elided]
It's probobly because of the domains in which I work, but I
don't think I've ever cared whether a zero is positive or
negative. I understand why it's easier to impliment things
that way, but I don't see why anybody would care. OTOH, NaNs
and Infinities are indisposable for real-world stuff.
>> I am not trying to say there is no way to do this. I am
>> trying to say it takes thought and effort on every detail, in
>> the definition, implementations, and unit tests.
>
> It's par for the course -- everyone thinks "this must be easy"
> at first, and everyone who persists eventually gives up.
> Kudos to Michael Hudson for persisting long enough to make
> major improvements here in pickle, struct and marshal for
> Python 2.5!
I would think it doable if one assumed IEEE-754 FP (famous last
words). I suppose there are still a few VAX machines around.
And there are things like TI DSPs that don't use IEEE-754.
--
Grant Edwards grante Yow! RELAX!!... This
at is gonna be a HEALING
visi.com EXPERIENCE!! Besides,
I work for DING DONGS!
--
http://mail.python.org/mailman/listinfo/python-list
