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.

classification
Title: script which sets random.seed still returns random value
Type: Stage:
Components: Library (Lib) Versions: Python 2.3
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: fmitha, rhettinger
Priority: normal Keywords:

Created on 2004-09-07 05:40 by fmitha, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
python_bug.tar.gz fmitha, 2004-09-07 05:40 Tar.gz file containing info to reproduce bug report (see README)
Messages (4)
msg22379 - (view) Author: Faheem Mitha (fmitha) Date: 2004-09-07 05:40
Hi,

The following text is in the README in the attached
tarball. Note also that I'd be happy to try to narrow
down the bug further, if indeed there is one. I just
wanted to confirm first that there indeed was a bug.

This is with python 2.3 and numarray 1.0 on Debian sarge.
ii  python-numarray            1.0-2                  
   An array processing package modelled after
Python-Numeric
ii  python                     2.3.4-1                
   An interactive high-level object-oriented language
(default version)

(By the way, I'd really, really prefer to submit
reports via email, like the Debian bug tracking
system). It is also not very convenient to follow up to
replies.
                                                      
                      Faheem

*************************************************************
Run the included script (requires python 2.3)

python bug.py

Even though the seed is set before gendata is called,
every time the script is run, a different matrix is
printed. It seems to me that this should not happen. My
interest in this case is ensuring
reproducibility for debugging purposes.

I am not an expert on random numbers, so I may be
missing some subtle point. If so, I'm appreciate it if
my error was explained to me.

Thanks.                                               
Faheem Mitha.
msg22380 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2004-09-07 08:47
Logged In: YES 
user_id=80475

There are two independent random number generators in your
code.  

One is in the random module and you're accessing it with
random.seed() and random.gammavariate().  The seed operation
will correctly make gammavariate() create a reproducable
sequence.

The second is in numarray.random_array.multinomial.  This
generator is provided by numarray and needs its own seed
operation.  Seed it, and your program ought to work fine. 
See the numarray docs for details on how to seed random_array.

For the future, please do not attach tar.gz files.  They are
a nuisance to review.  More importantly, you should pair
down the report to the simplest possible code that
reproduces the error.  Otherwise, a reviewer has to read all
of your code to figure out what you're doing.

Good luck and happy computing.
msg22381 - (view) Author: Faheem Mitha (fmitha) Date: 2004-09-07 22:19
Logged In: YES 
user_id=1063525


> Date: 2004-09-07 08:47
> Sender: rhettinger
> Logged In: YES 
> user_id=80475

> There are two independent random number generators in your
code.  

> One is in the random module and you're accessing it with
> random.seed() and random.gammavariate().  The seed operation
> will correctly make gammavariate() create a reproducable
> sequence.

> The second is in numarray.random_array.multinomial.  This
> generator is provided by numarray and needs its own seed
> operation.  Seed it, and your program ought to work fine. 
> See the numarray docs for details on how to seed random_array.

I see. Thanks for explaining this. I did try to track down
this bug, but I never realised that numarray was using a
different random number generator. I think it would be a
good idea to standardise on a single interface.

> For the future, please do not attach tar.gz files.  They are
> a nuisance to review.  

What do you want instead?

1) Code attached as text file?
2) Code included in the message? I don't think this would
work as the web form would probably mess up the indentation.
3) A link to a web page? But this would mean the info would
not be contained in the bug report for posterity. :-)

Or something else?

> More importantly, you should pair down the report to the
simplest 
> possible code that reproduces the error.  Otherwise, a
reviewer has to 
> read all of your code to figure out what you're doing.

Yes, I probably should have taken the time to narrow down
the problem, and in the process might have solved it. 

However, at the time I submitted, I had already run into
this problem several times without figuring it out, and had
spent some time narrowing down the problem to a region of
code. As I said in the report, I just 
wanted to confirm that this actually was a bug. As I also
said, I was quite  willing to spend additional time
narrowing it down if it was indeed a bug, but in in the
first place it seemed difficult since I had no idea why it
should occur. 

                                                           
                         Faheem.
msg22382 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2004-09-08 18:30
Logged In: YES 
user_id=80475

Since the two generators are in different products
(different people make and distribute Numeric), unifying
them would be a bit of a trick.  Consider posting a change
request on their site.
History
Date User Action Args
2022-04-11 14:56:06adminsetgithub: 40879
2004-09-07 05:40:27fmithacreate