[Numpy-discussion] one-offset arrays
Konrad Hinsen
hinsen at cnrs-orleans.fr
Wed Aug 29 05:01:10 CDT 2001
> 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. (C is by nature 0-indexed
> because it is so close to machine architecture, but with a little bit
I don't think this is a matter if numerics vs. machine orientation, it
is just an historical accident. Having used 0-based and 1-based
languages extensively, I find both perfectly suitable for numerical
work, and in my experience 0-based indexing leads to shorter index
expressions in many cases.
> symbols and function names for anther. However it can be damn tricky
> to convert 1-indexed code to 0-indexed code or visa versa without
> introducing any errors- believe me! (Yes it's possible to call nearly
Having done so recently, I agree :-(
> The other reason for choosing 1-based indexing is to keep the code as
> near to the standard notation as possible. This is one of the
I wouldn't call 1-based indexing "standard" - it all depends on your
background.
> question: as a simple example a spatial vector (x,y,z) is
> conventionally labelled 1,2,3 (1-indexed), but a relativistic
> four-vector with time included (t,x,y,z) is conventionally labelled
> 0,1,2,3 (0-indexed). So ideally one would be able to choose the
So, when you implement classes that represent vectors, you should
stick to whatever notation is common in the application domain.
I see bare-bones arrays as we have them in NumPy as a low-level
building block for high-level classes, i.e. not as a data type one
should use directly in non-trivial application code. It's not just
indexing, also operations. For your four-vectors, you would want a
method that calculates the norm in the Einstein metric, for example.
If you don't have a special four-vector class but use arrays directly,
any length calculation will look messy. That's what OO design is good
for. In fact, with special four-vector classes and appropriate
methods, there will hardly be any explicit indices in the application
code at all!
> indexing-type case-by-case. I'm sure that computer programmers will
> argue vehemently that code which mixes both 0-indexed and 1-indexed
> arrays is hard to understand and maintain, but for experts in a
Yes, if they are supposed to be the same data type. If different
classes use different indexing schemes, everything remains clear,
as long as the interactions between the classes are well defined.
> error-prone. In my case, I'm dealing at the moment with crystal
> structures with which are associated certain conventional sets of
> vectors and tensors - all 1-indexed by convention. I find it a
Have a look at the vector and tensor classes in Scientific Python
(http://dirac.cnrs-orleans.fr/programs/scientific.html). Although they
are 0-based as well (because I got so used to that!), you might find
that the predefined methods cover most of your needs and that explicit
indices are hardly needed. But you are also free to modify the
__getitem__ and __setitem__ methods to make the classes 1-based.
> I guess if I understood the reason for 0-indexed lists and tuples in
> Python I would be happier. In normal, everyday usage, sets,
Python has a very consistent indexing scheme, which you can best
understand in the following way: imagine that the indices are pointers
to positions *between* the elements:
elements a b c d
index 0 1 2 3 4
negative index -4 -3 -2 -1
Then all the slicing and indexing rules make a lot of sense, and
fulfill practically useful relations. For example, it is true that
x[a:b] + x[b:c] equals x[a:c]
for any list/array x, which would not be the case with 1-based
indices. Adding indices is also more straightforward with base 0, all
those "i+j-1" you see so frequently in Fortran code becomes just
"i+j".
Sure, everyday language works differently, but then you don't write
algorithms in everyday language, for a good reason.
> By the way, what is leave-last-one-out slicing? Is it
> a[:-1]
That one, as is clear from my little picture above.
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron | Fax: +33-2.38.63.15.17
45071 Orleans Cedex 2 | Deutsch/Esperanto/English/
France | Nederlands/Francais
-------------------------------------------------------------------------------
More information about the Numpy-discussion
mailing list