Thread: [Numpy-discussion] possible bug in seed argument

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Should
 >>> seed(1)
act the same as
 >>> seed(array([1]))
in the random module?
It generates a traceback with the Windows 1.0b1 binary.

Gary R.

Gary Ruben wrote:
> Should
>  >>> seed(1)
> act the same as
>  >>> seed(array([1]))
> in the random module?

No. They use slightly different mechanisms to seed. The integer uses RandomKit's 
seeding routine. I borrowed Python's mechanism for seeding from an array of 
integers. Now that it comes up, though, it is probably a good idea to use the 
same mechanism for both cases.

> It generates a traceback with the Windows 1.0b1 binary.

Please always copy-and-paste tracebacks when reporting bugs. It works for me 
with r2881; I'll rebuild with a later version and try again.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

See below:

Robert Kern wrote:
> Gary Ruben wrote:
>> Should
>>  >>> seed(1)
>> act the same as
>>  >>> seed(array([1]))
>> in the random module?
> 
> No. They use slightly different mechanisms to seed. The integer uses RandomKit's 
> seeding routine. I borrowed Python's mechanism for seeding from an array of 
> integers. Now that it comes up, though, it is probably a good idea to use the 
> same mechanism for both cases.
> 
>> It generates a traceback with the Windows 1.0b1 binary.
> 
> Please always copy-and-paste tracebacks when reporting bugs. It works for me 
> with r2881; I'll rebuild with a later version and try again.

Thanks Robert,
Here it is for reference. Not a very deep traceback:

 >>> seed(1)

Traceback (most recent call last):
   File "<pyshell#2>", line 1, in -toplevel-
     seed(1)
   File "mtrand.pyx", line 311, in mtrand.RandomState.seed
SystemError: C:\sf\python\dist23\src\Objects\longobject.c:240: bad 
argument to internal function

Gary Ruben wrote:
> See below:
>
> Robert Kern wrote:
>   
>> Gary Ruben wrote:
>>     
>>> Should
>>>  >>> seed(1)
>>> act the same as
>>>  >>> seed(array([1]))
>>> in the random module?
>>>       
>> No. They use slightly different mechanisms to seed. The integer uses RandomKit's 
>> seeding routine. I borrowed Python's mechanism for seeding from an array of 
>> integers. Now that it comes up, though, it is probably a good idea to use the 
>> same mechanism for both cases.
>>
>>     
>>> It generates a traceback with the Windows 1.0b1 binary.
>>>       
>> Please always copy-and-paste tracebacks when reporting bugs. It works for me 
>> with r2881; I'll rebuild with a later version and try again.
>>     
>
> Thanks Robert,
> Here it is for reference. Not a very deep traceback:
>   

It looks like this is a Python 2.3 error.  In Python 2.4, the 
PyLong_AsUnsignedLong was changed to accept Python  integers as well as 
Python longs. 

The problem with fixing it is I'm not sure where PyLong_AsUnsignedLong 
is being called.  I can't find that call in the current source code.  
It's possible that Pyrex changed and this function is no longer being 
used in mtrand.c

-Travis

Gary Ruben wrote:
> See below:
>
> Robert Kern wrote:
>   
>> Gary Ruben wrote:
>>     
>>> Should
>>>  >>> seed(1)
>>> act the same as
>>>  >>> seed(array([1]))
>>> in the random module?
>>>       
>> No. They use slightly different mechanisms to seed. The integer uses RandomKit's 
>> seeding routine. I borrowed Python's mechanism for seeding from an array of 
>> integers. Now that it comes up, though, it is probably a good idea to use the 
>> same mechanism for both cases.
>>
>>     
>>> It generates a traceback with the Windows 1.0b1 binary.
>>>       
>> Please always copy-and-paste tracebacks when reporting bugs. It works for me 
>> with r2881; I'll rebuild with a later version and try again.
>>     

I can verify that this now works with numpy 1.0b1 on Python 2.3.  The 
change was using an updated Pyrex for generating mtrand.c (it no longer 
calls PyLong_AsUnsignedLong on integer objects as it did before).

-Travis

Travis Oliphant wrote:
> I can verify that this now works with numpy 1.0b1 on Python 2.3.  The 
> change was using an updated Pyrex for generating mtrand.c (it no longer 
> calls PyLong_AsUnsignedLong on integer objects as it did before).
>
>   

Scratch that.  I meant it works with latest numpy (will be 1.0b2) 
because the mtrand.c was not re-generated until recently.

-Travis

Thread: [Numpy-discussion] possible bug in seed argument

A package for scientific computing with Python

numpy-discussion