Python "why" questions
in [Python]
|
Prev: Is there any way to minimize str()/unicode() objects memory usage[Python 2.6.4] ?
Next: sched() function questions
From: Den on 13 Aug 2010 11:27 > ... However, the killer reason is: "it's what everybody > else does. If this were really true, lists would be 1-based. I go back to WATFOR; and Fortran (and I believe Cobol and PL/I, though I'm not positive about them) were 1-based. (Now that I think about it, PL/I, knowing IBM, could probably be set to use either) Back then, everyone else was doing 1-based lists. In my opinion, the reason lists are 0-based started with a lazy programmer who decided that his own comfort (using 0-based addressing at the machine level and not having to translate the high-level 1- based language index into a low-level 0-based index) was paramount over teaching the language and having it make sense in the real world. After all, not even Brian Kernighan thinks books start on page 0. I'm not singling out C in this case because it is a relatively low- level language for low-level programmers and 0-based lists make perfect sense in that context. But then every compiler/interpreter programmer after that stopped caring about it. I smile every time I see the non-nonsensical sentence "The first thing, therefore, is in thing[0]" in a programming language learning book or tutorial. I laugh every time I hear someone defend that as common sense. Every three year old watching Sesame Street knows counting things starts with '1', not '0'. When you were three and you counted your blocks, you started with '1', not '0'. The whole rest of the world understands that implicitly, even if their counting starts '1', '2', 'many'. 0-based lists are NOT common sense. They only make sense to the programmers of computer languages, and their fanbois. There may be loads of reasons for it, but don't throw common sense around as one of them. Den
From: Thomas Jollans on 13 Aug 2010 13:14 On 2010-08-13 17:27, Den wrote: > There may be loads of reasons for it, but don't throw common sense > around as one of them. > It's a good thing then that I didn't: >> ... However, the killer reason is: "it's what everybody >> else does. >> > "Where it all started" is that 0-based indexing gives languages like C a very nice property: a[i] and *(a+i) are equivalent in C. From a language design viewpoint, I think that's quite a strong argument. Languages based directly on C (C++, Objective C, ...) can't break with this for obvious reasons, and other language designers/implementers imitated this behaviour without any good reason to do so, or not to do so. In higher-level languages, it doesn't really matter. 1-based indexing might seam more intuitive, but in the end, it's just another thing you have to learn when learning a language, like "commas make tuples", and somebody studying a programming language learns it, and gets used to it if they aren't used to it already.
From: Neil Cerutti on 13 Aug 2010 13:36 On 2010-08-13, Thomas Jollans <thomas(a)jollans.com> wrote: > 1-based indexing might seam more intuitive, but in the end, > it's just another thing you have to learn when learning a > language, like "commas make tuples", and somebody studying a > programming language learns it, and gets used to it if they > aren't used to it already. I think the main reason zero-based indexing is chosen in higher level languages is the following useful property: x[n:m] + x[m:len(x)] == x -- Neil Cerutti
From: Martin Gregorie on 13 Aug 2010 13:53 On Fri, 13 Aug 2010 19:14:44 +0200, Thomas Jollans wrote: > "Where it all started" is that 0-based indexing gives languages like C a > very nice property: a[i] and *(a+i) are equivalent in C. From a language > design viewpoint, I think that's quite a strong argument. Languages > based directly on C (C++, Objective C, ...) can't break with this for > obvious reasons, and other language designers/implementers imitated this > behaviour without any good reason to do so, or not to do so. In > higher-level languages, it doesn't really matter. 1-based indexing might > seam more intuitive. > In a higher level language 1-based indexing is just as limiting as 0- based indexing. What you really want is the ability to declare the index range to suit the problem: in Algol 60 it is very useful to be able to declare something like: real sample[-500:750]; and Algol 68 went even further: flex [1:0] int count where the array bounds change dynamically with each assignment to 'count'. Iteration is supported by the lwb and upb operators which return the bounds of an array, so you can write: for i from lwb count to upb count do.... -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Lie Ryan on 13 Aug 2010 14:31
On 08/10/10 06:36, Bartc wrote: > And if the context is Python, I doubt whether the choice of 0-based over a > 1-based makes that much difference in execution speed. And I doubt anyone cares about execution speed when deciding whether to use 1-based or 0-based array. The reason why you want to choose the alternative that use less conversion to the other system is to simplify the source code. Many common mathematical/physics/economics formulas are expressed much simply if we use 0-based counting: * arithmetic series: - 1-based: s(n) = a + (n - 1) * d - 0-based: s(n) = a + n * d * geometric series: - 1-based: g(n) = a * r**(n - 1) - 0-based: g(n) = a * r**n * equation of motion: - 1-based: x(t) = a + 1/2 * a * (t - 1)**2 - 0-based: x(t) = a + 1/2 * a * t**2 * exponential growth/decay: - 1-based: d(t) = a * e**(k * (t - 1)) - 0-based: d(t) = a * e**(k*t) In fact, most textbooks would already uses 0-based formula for some of these formulas already. Most physics and economic textbooks would show the base 0 variation of the formula, and refers to t=0 as the point in time where the "event" started. I often used this model of thinking for 0-based array indices (and negative indices): -7 -6 -5 -4 -3 -2 -1 +---+---+---+---+---+---+---+ | c | h | a | r | l | i | e | +---+---+---+---+---+---+---+ 0 1 2 3 4 5 6 (7) instead of: In short, the choice of 0-based array is of practical purpose, rather than historical purpose. |