Raymond Hettinger added the comment:
Marking this as closed -- the original bug doesn't seem to be reproducible.
See additional reasons and discussion in Issue #24567.
--
resolution: -> works for me
stage: -> resolved
status: open -> closed
___
Mark Dickinson added the comment:
[Tim]
I suspect, but have not proved, that 1. - 2.**-53 is the only
random.random() result for which it's possible that double-rounding
can cause int(i * random.random()) == i.
I'm sure this is true. Any other random value is at most 1 - 2**-52, and we're
Serge Anuchin added the comment:
Serge, you'll have to find some way to get more information on exactly what
is failing in order for this issue to make progress.
This exception occurred only once and I can't reproduce it.
Additional system specs in attachment.
--
Added file:
Stefan Krah added the comment:
Any chance that another program (C-extension) had set the FPU control
word to an unusual value (24bit prec?).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24546
Tim Peters added the comment:
Thanks, Mark! That's convincing. Just as a sanity check, I tried all ints in
1 through 4 billion (inclusive) against 1. - 2.**-52, with no failures.
Although that was with ad hoc Python code simulating various rounding methods
using scaled integers, so may
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
assignee: rhettinger -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24546
___
___
Mark Dickinson added the comment:
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
Tim Peters added the comment:
Mark, note that the sequence in the OP's original report only contains 35
elements. That, alas, makes double rounding irrelevant to this bug report.
That is, while random.choice() can suffer double-rounding surprises in _some_
cases, it cannot in the case
Mark Dickinson added the comment:
Tim: yes, I agree that this shouldn't happen for the string posted.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24546
___
Tim Peters added the comment:
Raymond, there are (at least) two bugs here:
1. The original bug report. Nobody yet has any plausible theory for what went
wrong there. So won't fix wouldn't be appropriate. If the OP can't provide
more information, neither a reproducible test case, then after
Steven D'Aprano added the comment:
I've created a new issue 24567 for the double-rounding bug. I have taken the
liberty of copying the nosy list from this issue to the new one, apologies if
that is inappropriate.
--
assignee: - rhettinger
___
Raymond Hettinger added the comment:
I would like to close this as won't fix.
Add given the infinitesimal probability of occurrence (and long standing code),
I don't think there needs to be a change to the documentation either.
--
___
Python
Steven D'Aprano added the comment:
I've been running this snippet for almost 72 hours now:
s = uБГДЖИЛЦЫЭu042eЯАВЕКМРТu042312456789
while True:
state = random.getstate()
try:
a = random.choice(s)
except IndexError:
break
with no results yet. I cannot replicate the
R. David Murray added the comment:
OK, so we don't know what caused the OPs original problem, and at the moment we
don't have enough info to figure it out. Serge, you'll have to find some way
to get more information on exactly what is failing in order for this issue to
make progress.
Stefan Krah added the comment:
Just to defend gcc. :) I still cannot reproduce Steven's problem
even with the C example and -m32.
Steven's gcc [GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] is very old
and probably has quite a lot of distro patches.
I'd try a modern vanilla version.
--
Serge Anuchin added the comment:
Which platform Python is that?
Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48) [GCC 4.4.5] on linux2
Linux li307-195 2.6.39.1-x86_64-linode19 #1 SMP Tue Jun 21 10:04:20 EDT 2011
x86_64 GNU/Linux
--
___
Python
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
assignee: rhettinger -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24546
___
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24546
___
___
Stefan Krah added the comment:
Very surprising! Which platform Python is that?
I'm unable to reproduce this using Linux-amd64, Python 2.7.6, gcc 4.8.2.
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24546
Steven D'Aprano added the comment:
On Thu, Jul 02, 2015 at 04:05:45AM +, Tim Peters wrote:
Very surprising! Which platform Python is that?
Python 2.7.2 (default, May 18 2012, 18:25:10)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] on linux2
I get the same result on Python 2.6 and 3.3, but
STINNER Victor added the comment:
Your example of int(0.5) returning 1 is misleading
On my setup, this number is rounded 1.0:
float('0.5').hex()
'0x1.0p+0'
CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
OS: Fedora release 22
Python 2.7.10 or 3.4.2
Steven D'Aprano added the comment:
On Thu, Jul 02, 2015 at 05:35:53PM +, Tim Peters wrote:
Steven, there's something wrong with the arithmetic on your machine,
but I can't guess what from here (perhaps you have a non-standard
rounding mode enabled, perhaps your CPU is broken, ...).
Tim Peters added the comment:
Thanks for the legwork, Steven!
So far it looks like a gcc bug when using -m32 (whether ints, longs and/or
pointers are 4 or 8 bytes _should_ make no difference to anything in Jason
Swails's C example).
But it may be a red herring anyway: there's only one
Tim Peters added the comment:
I'm guessing this is a double rounding problem due to gcc not restricting an
Intel FPU to using 53 bits of precison:
In binary, (2**53-1)/2**53 * 2049 is:
0.1
times
1001.0
which is exactly:
Tim Peters added the comment:
Should also note that double rounding cannot account for the _original_ symptom
here. Double rounding surprises on Intel chips require an exact product at
least 65 bits wide, but the OP's sequence is far too short to create such a
product. (Steven's 2049 just
Tim Peters added the comment:
Steven, there's something wrong with the arithmetic on your machine, but I
can't guess what from here (perhaps you have a non-standard rounding mode
enabled, perhaps your CPU is broken, ...).
In binary, (2**53-1)/2**53 * 2049 is:
R. David Murray added the comment:
perhaps you have a non-standard rounding mode enabled
I think Mark added code to python3 at least to handle non-standard rounding
modes being set, but I'm not sure.
--
nosy: +r.david.murray
___
Python tracker
New submission from Serge Anuchin:
It seems there is minor bug in random.choice.
I've got traceback from my server with IndexError from random.choice, but
sequence wasn't empty (seq value was:
u'\u0411\u0413\u0414\u0416\u0418\u041b\u0426\u042b\u042d\
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
assignee: - rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24546
___
___
Tim Peters added the comment:
random() may return 1.0 exactly
That shouldn't be possible. Although the code does assume C doubles have at
least 53 bits of mantissa precision (in which case it does arithmetic that's
exact in at least 53 bits - cannot round up to 1.0; but _could_ round up if
Tim Peters added the comment:
FYI, where x = 1.0 - 2.**-53, I believe it's easy to show this under IEEE
double precision arithmetic:
For every finite, normal, double y 0.0,
IEEE_multiply(x, y) y
under the default (nearest/even) rounding mode. That implies
int(x*i) i
for every
Steven D'Aprano added the comment:
Your example of int(0.5) returning 1 is misleading, because
0.999...95 is already 1.0. (1.0 - 1/2**53) = 0. is the nearest
float distinguishable from 1.0.
It seems to me that either random() may return 1.0 exactly (although
32 matches
Mail list logo