Some slices of Numeric.array are wrong

[Marcin Kowalczyk]

Binary package hint: python-numeric

This is Hardy on x86_64 with python-numeric 24.2-8ubuntu2:

$ python
Python 2.5.2 (r252:60911, Jul 31 2008, 17:31:22)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Numeric
>>> Numeric.array([[10,20],[30,40]],'s')[1:]
zeros((0, 2), 's')
>>> Numeric.array([[10,20],[30,40]],'s')[1:,]
array([ [30, 40]],'s')

The result of the slice with [1:] is wrong. It should be the same as the second slice. The bug seems to affect one-dimensional array slices with no ending point.

The bug is not present in Intrepid on x86 (Python 2.5.2 (r252:60911, Aug 6 2008, 09:17:42; [GCC 4.3.1]; python-numeric 24.2-9).

An application affected by this bug is ttx from fonttools.

[mazerj (james-mazer)]

Same problem in karmic 9.10 x64 (Numeric 24.2, python 2.6.4 and
2.5.4).

It may be a 64/32bit problem, since it doesn't happen on my
32bit 9.04 machines (don't have a 32bit 9.10 install to test)

The problem is that an unspecified stride gets set to 0 under some
circumstances. Here's a minimal fragment to show the problem:

>>> Import Numeric, numpy
>>> Numeric.arange(1,5)[2:]
>>> zeros((0,), 'l')
>>> numpy.arange(1,5)[2:]
array([3, 4])
>>> range(1,5)[2:]
[3, 4]

numpy and builtin range show the correct behavior, Numeric's
wrong. This is a fairly serious problem for people using Numeric
for number crunching..

[MKrause (mrkrause-gmail)]

I can confirm that this is a 32/64 bit problem.

On 32-bit karmic 9.10 (using Numeric 24.2, python 2.6.4), I get the expected behavior:
>>> Numeric.arange(0,3)[1:]
array([1, 2])
>>> Numeric.arange(0,3)[1::]
array([1, 2])

Using the same versions on 64-bit karmic/9.10, I get the following:
>> Numeric.arange(0,3)[1:] #This gives the wrong answer
zeros((0,), 'l')
>>> Numeric.arange(0,3)[1::] #This seems to work
array([1, 2])

[mazerj (james-mazer)]

Still not resolved in Lucid 10.04 LTS. Any thoughts here?