Live data from Hacker News

Why We Start Indexing from 0 in Computer Science

cs.utexas.edu

11–20 of 38 posts

Re: Why We Start Indexing from 0 in Computer Science

#11
2..13 2:13 2->13

Again we fall in the trap of endless discussions about bitheads, numheads and charheads.

The bithead will always think in zeros and ones, he is a hardcore c or c++ programmer, and his brain is damaged beyond repair. Avoid all discussions with that kind of specimen.

The numhead accepts both conventions, he is a python or ruby programmer, practical and gets the job done, he may ask why that weird convention but still goes on using it since it solves all his problems as it is.

The charhead is a vb or js programmer by luck, not by choice, he will never understand why we start from zero and will curse everytime he writes a for loop.

I've been in the three camps luckily escaping without any brain damage (I believe) and after 20 years programming I still prefer to count starting by one, like any human being.

Re: Why We Start Indexing from 0 in Computer Science

#12
A helpful way to think about this, especially when working in languages that have an array slice syntax, is that arrays are like rulers for measurement.

Like a ruler, the array has markers (ticks) going from 0 to N, and the array elements are stored between ticks. So the index numbers simply refer to points, while the array elements have a "one-dimensional" extent.

With that mental model, starting at 0 falls into place very naturally.

Re: Why We Start Indexing from 0 in Computer Science

#13
The note is really about the best way to specify a range/sequence of integers, not why we start from 0 as an index.

But it is an excellent example of thoughtful reasoning to choose between multiple (seemingly arbitrary) design options. I think we all benefit when language (and API) designers are as thoughtful as this.

Re: Why We Start Indexing from 0 in Computer Science

#14
post #7

I suspect the real reason has more to do with the pragmatics of machine code. It's extremely common to want to refer to some dynamic offset of a fixed location in memory, like if you have an array of equal-length items stored consecutively. If you have two literal addresses called Start and Index, you'd like to be able to say something like "Start[Index]" and have it mean "Read from Index, and whatever number is ther…

Right, it makes sense when dealing with machine code and when making the compiler do extra work for you (converting one-based to zero-based indexing) would be too much work for the compiler implementer or is too slow (like on machines back in the 70s and 80s) or it would abstract too far from what is happening underneath the hood, possibly leading to errors. But like many features of programming languages and operati…

You're vastly oversimplifying. In physics and finance, the "initial time" has always been t_0, not t_1. This has absolutely nothing to do with machine code, or with "blind cargo-cult copying". There are intrinsic reasons for doing it this way, which I'll leave for you to ponder yourself, ideally in a quiet room in a lotus position.

Traditions are not always arbitrary. Don't dismiss them until you're damned sure why they've survived, especially when you know for a fact that quantitative fields filled with high-order geniuses haven't bothered to scrap them. "Cargo-cult" thinking is a pernicious influence, but it's exceptionally rare that it's the complete explanation of anything.

Re: Why We Start Indexing from 0 in Computer Science

#16

Earlier quoted context omitted.

Right, it makes sense when dealing with machine code and when making the compiler do extra work for you (converting one-based to zero-based indexing) would be too much work for the compiler implementer or is too slow (like on machines back in the 70s and 80s) or it would abstract too far from what is happening underneath the hood, possibly leading to errors. But like many features of programming languages and operati…

You're vastly oversimplifying. In physics and finance, the "initial time" has always been t_0, not t_1. This has absolutely nothing to do with machine code, or with "blind cargo-cult copying". There are intrinsic reasons for doing it this way, which I'll leave for you to ponder yourself, ideally in a quiet room in a lotus position. Traditions are not always arbitrary. Don't dismiss them until you're damned sure why t…

I'm addressing the topic of the post: the use of indexes in programming, not names used for variables that store an initial time.

myarray[2] doesn't mean 'myarray at time 2'

Re: Why We Start Indexing from 0 in Computer Science

#19

Earlier quoted context omitted.

You're vastly oversimplifying. In physics and finance, the "initial time" has always been t_0, not t_1. This has absolutely nothing to do with machine code, or with "blind cargo-cult copying". There are intrinsic reasons for doing it this way, which I'll leave for you to ponder yourself, ideally in a quiet room in a lotus position. Traditions are not always arbitrary. Don't dismiss them until you're damned sure why t…

I'm addressing the topic of the post: the use of indexes in programming, not names used for variables that store an initial time. myarray[2] doesn't mean 'myarray at time 2'

One advantage I think the parent is alluding to, is that zero-based indexing makes it a bit easier and more natural to generalise between continuous (functions on R) and discontinuous (functions on N) situations.

Since the latter are often used to approximate the former, this is quite handy.

Re: Why We Start Indexing from 0 in Computer Science

#20
post #13

The note is really about the best way to specify a range/sequence of integers, not why we start from 0 as an index. But it is an excellent example of thoughtful reasoning to choose between multiple (seemingly arbitrary) design options. I think we all benefit when language (and API) designers are as thoughtful as this.

> The note is really about the best way to specify a range/sequence of integers, not why we start from 0 as an index.

Dijkstra deals with what index start with as well, but it comes out as a consequence of which bounds to choose for a range, so it's rather short.

From the article:

When dealing with a sequence of length N, the elements of which we wish to distinguish by subscript, the next vexing question is what subscript value to assign to its starting element. Adhering to convention a) yields, when starting with subscript 1, the subscript range 1 ≤ i

Post reply on HN