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 mark.dickinson
Recipients Serge Anuchin, mark.dickinson, pitrou, r.david.murray, rhettinger, serhiy.storchaka, skrah, steven.daprano, tim.peters, vstinner
Date 2018-06-26.07:58:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1529999926.84.0.56676864532.issue24567@psf.upfronthosting.co.za>
In-reply-to
Content
[Tim]
> Mark, do you believe that 32-bit Linux uses a different libm?

I don't know. But I'd expect to see accuracy losses as a result of forcing 53-bit precision, and I wouldn't be totally surprised to see other more catastrophic failure modes (infinite iterations, for example). But I don't have any concrete information on the subject.

There's this from (an unofficial mirror of) the glibc x86 sources: https://github.com/bminor/glibc/blob/43b1048ab9418e902aac8c834a7a9a88c501620a/sysdeps/x86/fpu_control.h#L69

> #define _FPU_EXTENDED 0x300	/* libm requires double extended precision.  */

But it's not clear to me whether that comment is intended to be a statement of fact, or indeed whether it's still true or just an ancient comment that should have been culled long ago.

Like I said, I just don't know, but I'd be worried about the law of unintended consequences.

Of course, with my Enthought hat on, I don't care, because we stopped worrying about 32-bit Linux long ago... :-)
History
Date User Action Args
2018-06-26 07:58:46mark.dickinsonsetrecipients: + mark.dickinson, tim.peters, rhettinger, pitrou, vstinner, steven.daprano, r.david.murray, skrah, serhiy.storchaka, Serge Anuchin
2018-06-26 07:58:46mark.dickinsonsetmessageid: <1529999926.84.0.56676864532.issue24567@psf.upfronthosting.co.za>
2018-06-26 07:58:46mark.dickinsonlinkissue24567 messages
2018-06-26 07:58:46mark.dickinsoncreate