Message95066
| Author |
mark.dickinson |
| Recipients |
mark.dickinson, skrah |
| Date |
2009年11月09日.10:49:27 |
| SpamBayes Score |
1.926792e-13 |
| Marked as misclassified |
No |
| Message-id |
<1257763770.26.0.0856855931161.issue7281@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Yes, I don't think Python 2.6 had a deliberate workaround. I suspect
that it's just that one version of Python happened to use something like
0.0/0.0 to generate NaN, while another used some equivalent of
strtod("nan", ...).
I also remember noticing at some point that even on a single machine/OS,
the sign bit of 0.0/0.0 depends on which version of gcc and which
optimization flags are present.
So I think we're in agreement that there's no need to change anything
here; I'll close this issue.
But: I really *would* like to get the short float repr working with
suncc! Issue #5792 is already open for this, so discussion should move
there. (This is about much more than consistent nan signs:
implementing short float repr gives a whole bunch of benefits: correctly
rounded float <-> string conversions (including all float formatting
operations), a correctly rounded 'round' function, a prettier float
repr, ...). |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2009年11月09日 10:49:30 | mark.dickinson | set | recipients:
+ mark.dickinson, skrah |
| 2009年11月09日 10:49:30 | mark.dickinson | set | messageid: <1257763770.26.0.0856855931161.issue7281@psf.upfronthosting.co.za> |
| 2009年11月09日 10:49:29 | mark.dickinson | link | issue7281 messages |
| 2009年11月09日 10:49:27 | mark.dickinson | create |
|