From: Konrad H. <hi...@cn...> - 2001-08-29 10:01:41
|
> 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: hi...@cn... 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 ------------------------------------------------------------------------------- |