This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients Serge Anuchin, mark.dickinson, pitrou, r.david.murray, rhettinger, serhiy.storchaka, skrah, steven.daprano, tim.peters, vstinner
Date 2018-06-25.21:19:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1529961567.54.0.56676864532.issue24567@psf.upfronthosting.co.za>
In-reply-to
Content
Mark, do you believe that 32-bit Linux uses a different libm?  One that fails if, e.g., SSE2 were used instead?  I don't know, but I'd sure be surprised it if did.  Very surprised - compilers have been notoriously unpredictable in exactly when and where extended precision gets used in compiled code, so sane code (outside of assembler) doesn't rely on it.

I'd be similarly surprised if hypothetical 3rd party libraries _assuming_ extended arithmetic existed.  Any sane person writing such a library would take it upon themselves to force extended precision on entry (if that's what they wanted), and restore the original FPU control state on exit.

I'm no more worried about this than, say, worried about that some dumbass platform may set the rounding mode to "to plus infinity" by default - and I wouldn't hesitate there either for Python startup to force it to nearest/even rounding.  Sure, there _may_ be some library out there for such a platform that assumes +Inf rounding, but I fundamentally don't care ;-)

In any case, `random` remains a red herring.  There are potential gratuitous numeric differences all over the place.
History
Date User Action Args
2018-06-25 21:19:27tim.peterssetrecipients: + tim.peters, rhettinger, mark.dickinson, pitrou, vstinner, steven.daprano, r.david.murray, skrah, serhiy.storchaka, Serge Anuchin
2018-06-25 21:19:27tim.peterssetmessageid: <1529961567.54.0.56676864532.issue24567@psf.upfronthosting.co.za>
2018-06-25 21:19:27tim.peterslinkissue24567 messages
2018-06-25 21:19:27tim.peterscreate