[Numpy-discussion] Weird behavior of gufuncs

[Jaime Fernández del Río]

Hi all,

I am seeing some very weird behavior on a gufunc I coded.

 It has a pretty complicated signature:
'(r,c,p),(i,j,k,n),(u,v),(d),(n,q)->(q,r,c)'

And a single registered loop function, for types:
uint8, uint16, uint16, uintp, uint8->uint8.

In general it performs beautifully well, returning the expected results
about x10 faster than a MATLAB version using a 12 core CPU (!) But today I
found out that for certain sizes of the inputs, it doesn't even call the
loop function and returns a zeroed output array immediately.

I am using Python 2.7.5 and Numpy 1.7.1 under Windows 7, and have seen the
behavior in both x64 and x86 versions. The thresholds vary, and I don't
fully understand the logic behind it, but there is a clear threshold of
sizes: keeping all other inputs the same, one byte more in the other
argument and it returns all zeros, one byte less and everything works fine.
The thresholds are different for 64 and 32 bit versions.

I have a strong suspicion that this may be a NumPy 1.7 bug, because a
colleague running MacOS and NumPy 1.8 compiled from the development branch
isn't seeing any of this issues I have. It could of course be a Windows
thing, but somehow that seems less likely, especially since there are other
bugs in gufuncs that have been fixed in 1.8 but haven't been backported to
1.7. Tomorrow I am going to try and get access to a Linux box with Numpy
1.7 to try to reproduce it there.

Does this sound familiar to anyone? Any known (and hopefully solved) issue
that could trigger this behavior? A search for ufunc in github's issue
tracker didn't give me any meaningful leads...

Thanks!

Jaime
-- 
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
de dominación mundial.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20130905/4b414154/attachment.html>