I recently noticed that the standard random() function generates values >= 1.0

As processes are called from an event scheduler, each process has its own Random() instance.

    self.random = random.Random(seed)
    self.randomState = self.random.getstate()



keeping track of multiple objects:

    self.random.setstate(self.randomState)
    self.random.jumpahead(1)
    self.randomState = self.random.getstate()


Also gammavariate() generates errors as it too makes use of the _random() call

A workaround is to check each response of random() for values >= 1.0

Can you post a small program that demonstrates the problem?  I'm certainly not seeing a problem just calling random.random() (and would be very surprised if I did).

This could be a duplicate of issue14591.

That indeed looks likely.  Fortunately there will be a new release of 2.7 including that fix soon.

Floris, do you have any way to test against 2.7 tip?

On 23 Jan 2013, at 19:18, R. David Murray wrote:

> 
> R. David Murray added the comment:
> 
> That indeed looks likely.  Fortunately there will be a new release of 2.7 including that fix soon.
> 
> Floris, do you have any way to test against 2.7 tip?

using 2.7.3 as well as pypy (based on 2.7.3) via macport.
pypy version suffers from the same issue.

i'm not (yet) familiar how to get the tip from 2.7.3
hint?

.F

indeed, looks like the same.
.F

On 23 Jan 2013, at 19:09, Peter Otten wrote:

> 
> Peter Otten added the comment:
> 
> This could be a duplicate of issue14591.
> 
> ----------
> nosy: +peter.otten
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue17020>
> _______________________________________

hg pull http://hg.python.org/cpython
hg up 2.7

There are also git and bzr mirrors, but I don't know their urls or how up to date they are.

We could also just close this as a dup if you are pretty sure its the same problem (which it certainly sounds like it is) and you could post to that issue if your problem isn't solved by the RC for 2.7.4.

Can you show how you determined that you got a value >= 1.0 or provide a seed that reproduces the problem?

I'm not seeing an issue on the 2.7.3 64-bit Mac build:

>>> from itertools import starmap, repeat
>>> from random import random, seed
>>> seed(56019413053459019451450201)
>>> for i in range(20):
	print max(starmap(random, repeat((), 10000000)))

	
0.999999787916
0.999999859769
0.999999809486
0.99999968575
0.999999886565
0.999999991274
0.999999886922
0.999999874948
0.999999987989
0.999999751067
0.999999999353
0.999999935037
0.999999919091
0.999999664265
0.999999951016
0.999999998665
0.999999919618
0.999999786864
0.999999874042
0.999999967453

It is in the combination with jumpahead(), getstate(), setstate() that you'll experience random() to produce values >= 1.0

.F

On 25 Jan 2013, at 06:24, Raymond Hettinger wrote:

> 
> Raymond Hettinger added the comment:
> 
> Can you show how you determined that you got a value >= 1.0 or provide a seed that reproduces the problem?
> 
> I'm not seeing an issue on the 2.7.3 64-bit Mac build:
> 
>>>> from itertools import starmap, repeat
>>>> from random import random, seed
>>>> seed(56019413053459019451450201)
>>>> for i in range(20):
> 	print max(starmap(random, repeat((), 10000000)))
> 
> 	
> 0.999999787916
> 0.999999859769
> 0.999999809486
> 0.99999968575
> 0.999999886565
> 0.999999991274
> 0.999999886922
> 0.999999874948
> 0.999999987989
> 0.999999751067
> 0.999999999353
> 0.999999935037
> 0.999999919091
> 0.999999664265
> 0.999999951016
> 0.999999998665
> 0.999999919618
> 0.999999786864
> 0.999999874042
> 0.999999967453
> 
> ----------
> nosy: +rhettinger
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue17020>
> _______________________________________

> It is in the combination with jumpahead(), getstate(), setstate() that you'll experience random() to produce values >= 1.0

Let me reiterate what David said: Can you post a self-contained program
that exhibits the issue?

On 25 Jan 2013, at 11:07, Stefan Krah wrote:

> 
> Stefan Krah added the comment:
> 
>> It is in the combination with jumpahead(), getstate(), setstate() that you'll experience random() to produce values >= 1.0
> 
> Let me reiterate what David said: Can you post a self-contained program
> that exhibits the issue?

My program is sort of complex in the meaning of multiple processes interleaving and interacting via a priorityqueue.
Each individual steps through multiple classes which all should stay independent.
No simple short snippet.
From what i understand is that issue14591 was able to reproduce the same feature as it seems related to the jumpahead()  malfunctioning.

.F

Floris van Manen <report@bugs.python.org> wrote:
> From what i understand is that issue14591 was able to reproduce the same feature as it seems related to the jumpahead()  malfunctioning.

I'm also quite sure that it's the same issue. It would be nice to have
confirmation though. If you have the opportunity to compile the tip of
the 2.7 branch (where #14591 is fixed), get one of these:

http://hg.python.org/cpython/archive/864b9836dae6.tar.gz
http://hg.python.org/cpython/archive/864b9836dae6.zip

On 25 Jan 2013, at 19:35, Stefan Krah wrote:

> 
> Stefan Krah added the comment:
> 
> Floris van Manen <report@bugs.python.org> wrote:
>> From what i understand is that issue14591 was able to reproduce the same feature as it seems related to the jumpahead()  malfunctioning.
> 
> I'm also quite sure that it's the same issue. It would be nice to have
> confirmation though. If you have the opportunity to compile the tip of
> the 2.7 branch (where #14591 is fixed), get one of these:
> 
> http://hg.python.org/cpython/archive/864b9836dae6.tar.gz
> http://hg.python.org/cpython/archive/864b9836dae6.zip
> 

Did compile that version and it launches.
To test with my code i do not want to have it interfere with my current version.
I remember it is possible to setup n isolated environment with pip en virtualenv.
But i never did this so far.
Any hints / links to (simple) script explanation that could do the job?
Or is there an even simpler way?

.F

Floris van Manen <report@bugs.python.org> wrote:
> Did compile that version and it launches.
> To test with my code i do not want to have it interfere with my current version.
> I remember it is possible to setup n isolated environment with pip en virtualenv.
> But i never did this so far.
> Any hints / links to (simple) script explanation that could do the job?
> Or is there an even simpler way?

I wouldn't bother with virtualenvs yet. First I'd simply install python
into /tmp:

mkdir /tmp/usr
./configure --prefix=/tmp/usr/
make
make install

Then always call python with the full path. If your app is a simple
script, then:

/tmp/usr/bin/python app.py

If you have to install it:

/tmp/usr/bin/python setup.py install

On 25 Jan 2013, at 22:27, Stefan Krah wrote:

> Then always call python with the full path. If your app is a simple
> script, then:
> 
> /tmp/usr/bin/python app.py

ok.
and how do i add extra packages to that new python version ?
e.g. i need to install
pyyam and openpyxll

(sorry for the inconvenience)
.F

On 25 Jan 2013, at 22:27, Stefan Krah wrote:

> Then always call python with the full path. If your app is a simple
> script, t

ok, managed to install the extra packages and run the app.
Seems to work correctly now, no more random() >= 1.0

(thanks!)
.F

Excellent.  Thanks for testing.  And thanks for pointing out the duplicate, Peter.