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, r.david.murray, rhettinger, serhiy.storchaka, skrah, steven.daprano, tim.peters, vstinner
Date 2015-07-04.14:32:06
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1436020327.53.0.331753039899.issue24546@psf.upfronthosting.co.za>
In-reply-to
Content
Agreed with Tim Peters about this not being possible with fully compliant IEEE 754 arithmetic (see http://stackoverflow.com/a/3041071/270986 for a sketch of a proof), but it's certainly a possibility with double rounding, as Steven's result demonstrates.  And 32-bit Linux is currently the worst offender for double rounding: IIRC OS X uses the SSE2 instructions exclusively for floating-point arithmetic, and 64-bit Linux tends to do the same.  Windows uses the x87 FPU, but sets the FPU precision to 53-bits, so you don't see double rounding within the normal range (though it's still possible with computations having subnormal results).

So I'd say that yes, this *is* a bug in random.choice, though it's one that should show up very rarely indeed.
History
Date User Action Args
2015-07-04 14:32:07mark.dickinsonsetrecipients: + mark.dickinson, tim.peters, rhettinger, vstinner, steven.daprano, r.david.murray, skrah, serhiy.storchaka, Serge Anuchin
2015-07-04 14:32:07mark.dickinsonsetmessageid: <1436020327.53.0.331753039899.issue24546@psf.upfronthosting.co.za>
2015-07-04 14:32:07mark.dickinsonlinkissue24546 messages
2015-07-04 14:32:06mark.dickinsoncreate