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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion