[Numpy-discussion] one-offset arrays

[Chris Barker]

It's mostly been said already, but I can't help but add my $.02
sometimes...

Eric Nodwell wrote:

> >> Without one-offset indexing, it seems to me that Python is minimally
> >> useful for numerical computations. Many, perhaps the majority, of
> >> numerical algorithms are one-indexed. Matlab for example is one-based
> >> for this reason.  In fact it seems strange to me that a "high-level"
> >> language like Python should use zero-offset lists.

I was a heavy user of MATLAB for a long time before I discovered NumPy,
and I have to say that I like the 0-indexing scheme MUCH better!

> In my view, the most important reason to prefer 1-based indexing
> versus 0-based indexing is compatibility.  For numerical work, some of
> the languages which I use or have used are Matlab, Mathematica, Maple
> and Fortran. These are all 1-indexed.

Actually Fortran is indexed however you decide you want it:

DIMENSION array(0:9)

DIMENSION array(1:10) or DIMENSION array(10)

DIMENSION array(1900:1999)

Are all legal. This is a VERY handy feature, and I would say that I used
the 0-indexed version most often. The reason is related to C's pointer
arithmetic logic: Often the array would represent discrete points on a
continuous scale, so I could find the value of X, for instance, by
doing:

Xaxis(i) = MinX * i * DeltaX

with i-indexing, you have to subtract 1 all the time.

I suspect that the higher level nature of NumPy would make it a lot
harder to have arbitrary indexing of this fashion: if all you have to do
is access elements, it is easy, but if you have a whole collection of
array oriented operations, as NumPy does, you would probably have to
stick with one standard, and I think the 0-indexing standard is the
best.

> for experts in a
> particular field who are accustomed to certain ingrained notations, it
> is the code which breaks the conventional notation which is most
> error-prone.

This is why being able to set your own indexing notation is the best
option, but a difficult one to impliment.

> Python is otherwise such an elegant and
> natural language. Why the ugly exception of making the user conform to
> the underlying mechanism of an array being an address plus an offset?

I gave an example above, and others have too: Python's indexing scheme
is elegant and natural for MANY usages. As with many things Python
(indentation, anyone!), I found it awkward to make the transition at
first, but then found that it, in fact, made things easier in general.
For me, this is the very essence of truly usable design: it is designed
to make people most productive in the long run, not most comfortable
when they first start using it. 
 
> All this is really neither here nor there, since this debate, at least
> as far as Python is concerned, was probably settled 10 years ago and

Well, yes, and having NumPy different from the rest of Python would NOT
be a good idea either.

> I'm sure nobody wants to hear anything more about it at this point.
> As you point out, I can define my own array type with inheritance. I
> will also need my own range command and several other functions which
> haven't occured to me yet. I was hoping that there would be a standard
> module to implement this.

If it were truly generally useful, there probably would be such a
package. I imagine most people have found it easier to make the
transition than to write a whole package that would allow you not to
make the transition. If you really have a lot of code that is 1-indexed
that you want to translate, it may be worth the effort for you, and I'm
sure there are other folks that would find it useful, but remember that
it will always be incompatable with the rest of Python, which may make
it harder to use than you imagine. 

-Chris

-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker at home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------