[Numpy-discussion] Problems with Numexpr and discontiguous arrays

Tim Hochberg tim.hochberg at ieee.org
Wed Oct 4 11:32:24 CDT 2006


Ivan Vilata i Balaguer wrote:
> It seemed that discontiguous arrays worked OK in Numexpr since r1977 or
> so, but I have come across some alignment or striding problems which can
> be seen with the following code::
>
>     import numpy
>     import numexpr
>
>     array_length = 10
>     array_descr = [('c1', numpy.int32), ('c2', numpy.uint16)]
>
>     array = numpy.empty((array_length,), dtype=array_descr)
>     for i in xrange(array_length):
>         array['c1'][i] = i
>         array['c2'][i] = 0xaaaa
>
>     print numexpr.evaluate('c1', {'c1': array['c1']})
>     print numexpr.evaluate('c1', {'c1': array['c1'].copy()})
>
> Im my computer, Pentium IV with NumPy 1.0rc1 and Numexpr r2239
> (unmodified) this gives the following result::
>
>     [      0      109226 -1431699456           2      240298 -1431699456
>            4      371370           8      633514]
>     [0 1 2 3 4 5 6 7 8 9]
>
> The test works right when ``evaluate()`` is used with 'c2' instead of
> 'c1', and also when 'c2' also measures 32 bits and fields are aligned.
> Maybe the ``memsteps`` value is not getting used somewhere.  Any ideas
> on this?
>   
I suspect that there are some assumptions that the element separation  
is an integral multiple of the element size. I certainly didn't have 
record arrays in mind when I was working on the striding stuff, so it 
wouldn't surprise me. This should be fixed: preferably to do the right 
thing and at a minimum to cleanly raise an exception rather than 
spitting out garbage. I don't know that I'll have time to mess with it 
soon though.

-tim





More information about the Numpy-discussion mailing list