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
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Numpy-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
