On 10/3/07, Perry Greenfield <perry@stsci.edu> wrote:

On Sep 28, 2007, at 4:23 PM, Stefan van der Walt wrote:

> On Fri, Sep 28, 2007 at 03:07:30PM -0400, Nadia Dencheva wrote:
>> This should return an error and not silently truncate to int.
> Why do you say that?  The current behaviour is consistent and well
> defined:
> a[x] == a[int(x)]
I disagree. It is neither consistent nor well defined.

It is not consistent with Python list indexing behavior.

It is not consistent with numpy behavior:

>>> x = arange(10)
>>> x[array(2.99)]

raises an exception

It didn't work in Numeric
It didn't work in numarray

> We certainly can't change it now (just imagine all the code out there
> that will break); but I personally don't think it is a big problem.
I disagree. If people are willing to change the Class API of numpy to
be consistent with Python, they certainly should be willing to change
this. This behavior is new with numpy, so there should not be a lot
of code that depends on it (and shame on those that do :-).

> On a somewhat related note, you may also be interested in the PEP at
> http://docs.python.org/whatsnew/pep-357.html
I believe that this PEP is irrelevant. It's purpose is to allow numpy
rank-0 arrays (what numpy returns on indexing single values in
arrays) to be used as an index in Python lists. It does not suggest
that float values should be used as indices for sequences. It does
provide a mechanism so that numpy rank-0 float arrays could be used
as indices to lists, but doesn't mean that they should. And
currently, they don't work as indices to lists (try it).

So I can't see any reason not to treat the current behavior as
undesirable. It is not long standing (it wasn't available in numpy,
and only in odd ways in numarray--and it was a bug there [I feel I
can say that without contradiction :-)]. Now that the compatibility
can of worms is open, fixing this is a small thing compared to the
other issue being raised.

I agree that this should be changed, and the sooner the better. Look at how many problems arange with float arguments causes, and the often expressed wish that it had never allowed floats in the first place. I suspect using floats as indexes is almost always a bug, and where it isn't the code would be much clearer if the conversion to integer was made explicit.