Re: [Numpy-discussion] performance problem

[Gerard V. <ger...@gr...>]

On Mon, 30 Jan 2006 01:52:53 -0700
Travis Oliphant <oli...@ie...> 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