bug triggered by array.astype()
from numpy import * core.__version__ '0.9.5.2019' v = linspace(0, 2*pi) c = (255<<24)*cos(v) + (255<<16)*cos(v+2*pi/3) + (255<<8)*cos(v+4*pi/3) + 255 c.astype(UInt32) Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: Objects/longobject.c:257: bad argument to internal function
Gerard
Gerard Vermeulen wrote:
from numpy import * core.__version__
'0.9.5.2019'
v = linspace(0, 2*pi) c = (255<<24)*cos(v) + (255<<16)*cos(v+2*pi/3) + (255<<8)*cos(v+4*pi/3) + 255 c.astype(UInt32)
Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: Objects/longobject.c:257: bad argument to internal function
Thanks for this test. The problem stems from the (255<<24) which (on 32-bit platform) generates a long-integer object. Currently, long-integers are converted to object arrays, thus this operation causes your entire calculation to be done using Python objects. Then, you try to convert the whole thing to UInt32 which is giving the error. I'll look into the error. In the meantime, you can avoid going through object arrays using an int64 scalar: int64(255<24)*cos(v) + ... -Travis
Gerard Vermeulen wrote:
from numpy import * core.__version__
'0.9.5.2019'
v = linspace(0, 2*pi) c = (255<<24)*cos(v) + (255<<16)*cos(v+2*pi/3) + (255<<8)*cos(v+4*pi/3) + 255 c.astype(UInt32)
Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: Objects/longobject.c:257: bad argument to internal function
In SVN, now a Overflow error is raised instead in this example because negative long integer objects are trying to be converted to unsigned integers (this is a Python error being raised). We could check for this and instead do what the c-compiler would do in converting from signed to unsigned objects. Is that preferrable? -Travis
On Sun, 29 Jan 2006 01:50:57 -0700
Travis Oliphant
In SVN, now a Overflow error is raised instead in this example because negative long integer objects are trying to be converted to unsigned integers (this is a Python error being raised). We could check for this and instead do what the c-compiler would do in converting from signed to unsigned objects.
Is that preferrable?
Well, the current SVN does now almost what Numeric does:
from Numeric import * v = arange(0, 10, 1, Float32) c = (255<<24)*cos(v)+ (255<<16)*cos(v+2*pi/3) + (255<<8)*cos(v+4*pi/3) + 255 c.astype(UInt32) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: long int too large to convert to int
However, numarray does:
from numarray import * v = arange(0, 10, 1, Float32) c = (255<<24)*cos(v)+ (255<<16)*cos(v+2*pi/3) + (255<<8)*cos(v+4*pi/3) + 255 c.astype(UInt32) array([4269801984, 2294853120, 2504994432, 65861376, 1514949120, 1225005568, 4103764992, 3209541888, 3659448448, 398681088], type=UInt32)
This is more user friendly, but may cost more CPU cycles. Gerard
Gerard Vermeulen wrote:
On Sun, 29 Jan 2006 01:50:57 -0700 Travis Oliphant
wrote: [ .. ]
In SVN, now a Overflow error is raised instead in this example because negative long integer objects are trying to be converted to unsigned integers (this is a Python error being raised). We could check for this and instead do what the c-compiler would do in converting from signed to unsigned objects.
Is that preferrable?
Well, the current SVN does now almost what Numeric does:
from Numeric import * v = arange(0, 10, 1, Float32) c = (255<<24)*cos(v)+ (255<<16)*cos(v+2*pi/3) + (255<<8)*cos(v+4*pi/3) + 255 c.astype(UInt32)
Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: long int too large to convert to int
However, numarray does:
from numarray import * v = arange(0, 10, 1, Float32) c = (255<<24)*cos(v)+ (255<<16)*cos(v+2*pi/3) + (255<<8)*cos(v+4*pi/3) + 255 c.astype(UInt32)
array([4269801984, 2294853120, 2504994432, 65861376, 1514949120, 1225005568, 4103764992, 3209541888, 3659448448, 398681088], type=UInt32)
This is more user friendly, but may cost more CPU cycles.
The issue here is really that in Numeric (and numpy) c is an object array while in numarray c is a float array. Because Numeric and numpy support object arrays, long integers have been converted to objects. I think what should be changed is that long integers should only be converted to objects if they are bigger than the maximum integer-type on the platform. That is what numarray allows and makes sense. In other words, the root of this difference is what array(255<<24) returns. In Numeric and numpy it returns an object array. In numarray it returns a UInt64 array. -Travis
Gerard Vermeulen wrote:
from numpy import * core.__version__
'0.9.5.2019'
v = linspace(0, 2*pi) c = (255<<24)*cos(v) + (255<<16)*cos(v+2*pi/3) + (255<<8)*cos(v+4*pi/3) + 255 c.astype(UInt32)
Traceback (most recent call last): File "<stdin>", line 1, in ? SystemError: Objects/longobject.c:257: bad argument to internal function
This behaves like numarray now in numpy SVN where-in (255<<24) is converted to an int64 array during the multiplication step so that object arrays are not constructed. -Travis
participants (2)
-
Gerard Vermeulen
-
Travis Oliphant