On Mon, 30 Jan 2006 01:52:53 -0700
Travis Oliphant
Gerard Vermeulen wrote:
coercion issue snipped
In current SVN, I think improved on the current state by only calling a scalar a signed integer if it is actually negative (previously only it's data-type was checked and all Python integers get converted to PyArray_LONG data-types which are signed integers).
This fixes the immediate problem, I think.
What are opinions on this scalar-coercion rule?
Hmm, this is a consequence of your rule:
from numpy import *; core.__version__ '0.9.5.2024' a = arange(3, dtype=uint32) a-3 array([4294967293, 4294967294, 4294967295], dtype=uint32) a+-3 array([-3, -2, -1], dtype=int64) (a-3) == (a+-3) array([False, False, False], dtype=bool)
Do you think that the speed-up justifies this? I don't think so. All my performance issues are discovered while writing demo examples which transfer data between a Python wrapped C++-library and Numeric, numarray, or numpy. In that state of mind, it surprises me when an uint32 ndarray gets coerced to an int64 ndarray. I rather prefer numarray's approach which raises an overflow error for the
a+-3 above.
Agreed that sometimes a silent coercion is a good thing, but somebody who has started with an ubyte ndarray is likely to want an ubyte array in the end. I don't want to start a flame war, happy to write a - uint32(3) for numpy specific code. Gerard