[NumPy-Tickets] [NumPy] #1413: np.random.binomial() fails with int64 'n' argument on x86/32-bit

[NumPy Trac]

#1413: np.random.binomial() fails with int64 'n' argument on x86/32-bit
--------------------------------+-------------------------------------------
 Reporter:  david.warde-farley  |       Owner:  somebody
     Type:  defect              |      Status:  new     
 Priority:  normal              |   Milestone:          
Component:  numpy.random        |     Version:          
 Keywords:  mtrand, binomial,   |  
--------------------------------+-------------------------------------------
 Reported to the list by James Bergstra, confirmed by me:

 {{{
 >>> numpy.random.binomial(n=numpy.asarray([2,3,4], dtype='int64'),
 p=numpy.asarray([.1, .2, .3], dtype='float64'))
 }}}

 produces:

 {{{
 TypeError: array cannot be safely cast to required type
 }}}

 It seems to be not only 32-bit specific but x86-specific. On a ppc
 machine, 32-bit mode, it behaves as expected:

 {{{
 dwf@morrislab:~$ python-32
 Python 2.6.4 (r264:75706, Feb 16 2010, 21:03:46)
 [GCC 4.0.1 (Apple Inc. build 5493)] on darwin
 Type "help", "copyright", "credits" or "license" for more information.
 import numpy
 numpy.__version__
 '1.3.0'
 numpy.random.binomial(n=numpy.asarray([2,3,4], dtype='int64'),
 p=numpy.asarray([.1,.2,.3], dtype='float64'))
 array([1, 1, 2])
 }}}

 So it smells a bit like an endianness bug/problem with the definition of
 `NPY_LONG`.

 I can confirm the bug on OS X/Intel 32-bit, and Linux x86-32 (both
 1.3.0 and most recent svn trunk), as well as its absence on Linux
 x86-64. The problem seems to be with this line in
 [source:trunk/numpy/random/mtrand/mtrand.pyx mtrand.pyx], line
 3306 in the trunk:

 {{{
 on = <ndarray>PyArray_FROM_OTF(n, NPY_LONG, NPY_ALIGNED)
 }}}

-- 
Ticket URL: <http://projects.scipy.org/numpy/ticket/1413>
NumPy <http://projects.scipy.org/numpy>
My example project