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" 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.
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
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:
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
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
-7 -6 -5 -4 -3 -2 -1
| c | h | a | r | l | i | e |
0 1 2 3 4 5 6 (7)
In short, the choice of 0-based array is of practical purpose, rather
than historical purpose.