[Numpy-discussion] performance problem
Gerard Vermeulen
gerard.vermeulen at grenoble.cnrs.fr
Mon Jan 30 13:52:07 CST 2006
On Mon, 30 Jan 2006 01:52:53 -0700
Travis Oliphant <oliphant.travis at ieee.org> wrote:
> 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
More information about the Numpy-discussion
mailing list