Mark Dickinson <dicki...@gmail.com> added the comment:
You may have let yourself in for something here. :-)
Can you tell me what:
>>> import sys
>>> print sys.float_repr_style
gives for your Opensolaris/suncc/Python3.x combination? If it prints
'legacy', then I'd dearly like some help with making it read 'short'
instead. That would then make treatment of nans on that combination
consistent with other platforms.
All I really need to know is how to set the x87 (I'm assuming you're on
32-bit x86 here) FPU control word using suncc. Oh, and a willing victim
to test changes. Look for HAVE_PY_SET_53BIT_PRECISION in
Include/pyport.h for details.
Having said that, I don't really see this difference with nans as an
actual bug. Is it possible that float("nan") is simply giving a nan
with its sign bit set here, and that float("-nan") is giving a nan with
no sign bit set? That would actually be quite unsurprising, since
according to Intel's manuals, the 'default' NaN value returned by
invalid operations has its sign bit set. It would also be (I think)
quite legal: sign bits of NaNs don't make a lot of sense anyway, and I
don't think Python should specify anything about the sign bit (or indeed
the payload) of the NaN coming from float('nan').
In other words, I think it's not unreasonable to regard the sign of
copysign(x, y) as undefined whenever y is a nan. (I'm fairly sure that
MPFR takes this attitude, for example.)
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue7281>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
