[SciPy-user] Array Bounds
Fri Mar 9 21:59:55 CST 2007
On Mar 9, 2007, at 10:57 AM, Lorenzo Isella wrote:
> Dear All,
> Again a newbie question: I noticed that Python (or at least
> Numpy/Scipy) follows the C convention of labeling as zero the first
> element in an array.
> I can live with this, but I do not find very intuitive the loop
> for i in range (1,5 )
> means that i actually takes values 1,2,3,4 and not 5!
> Why this choice? Is it a consequence of the array labeling? In case
> one should not like it, can it be changed by the user?
> Kind Regards
Your reaction is quite common for those coming from a language that
uses 1-based indexing. But keep in mind there are also advantages for
0-based indexing that you aren't aware of since you haven't used it.
There are pros and cons to both (and yes, I've used both). Since
Python uses 0-based, it generally isn't a good idea to adopt
different conventions than the language uses for arrays. It may make
your array usage more comfortable, but will lead to all sorts of
problems when you use Python lists and tuples. (Note that you mention
arrays, but your example is actually due to Python list behavior and
the built-in range function, which has nothing to do with numpy; in
principle array indexing behavior could be made different than Python
list indexing behavior, but that would be a really bad thing to do).
Actually, your complaint is not directly due to that issue (though
it's related). As I read it, it's because you are surprised that the
end of the range does not include the number that's used for the end
of the range. And that's a natural enough reaction. It's not
intuitive to many people. But what's intuitive is not always the best
choice. It works that way (I'm guessing here) because slices in
Python work that way (e.g., mylist[1:5] doesn't include mylist).
Ok, why don't slices work that way? For various reasons, but one is
that when you break a list into two pieces, e.g., mylist = mylist[:7]
+ mylist[7:], you don't have to worry about dealing with those
annoying +1 or -1 offsets to get things right. In this case, the
number of items sliced is simply the difference of the two indices.
It may seem like a small point, but a lot of errors arise from
getting stuff like this wrong, especially the edge cases of when the
slice point is at 0 or the end of an array. The rules Python has
chosen for this stuff are consistent, and they do work pretty well.
So it isn't the most intuitive, especially to scientific or
engineering types, but it's not that hard to get used to, and there
are definite advantages to this approach.
More information about the SciPy-user