Numbering Should Start at Zero

Dijkstra have a certain way of writing as if his argument follows by logical necessity. But when you dig into the chain of reasoning, it hinges on the assertion that starting with 0 is &quot;nicer&quot;. Which is of course a valid opinion, but starting with 1 also have nice properties, for example that the numbering of elements corresponds to the ordinal numbers. Having the first element be element 1 is pretty nice IMHO.<p>He ends with the assertion &quot;In corporate religions as in others, the heretic must be cast out not because of the probability that he is wrong but because of the possibility that he is right.&quot; This sounds profound and edgy but is just an appeal to contrarians which can be used to justify absolutely anything. You criticize my theory X, that just shows how right I am! And anyway, isn&#x27;t the &quot;corporate religion&quot; these days to start with 0, since this as what the big mainstream languages does?

So the first item in my array of 13 items is at position &#x27;0&#x27;. The 3rd item is at position &#x27;2&#x27;.<p>And if I want to count the items in my array I start at &#x27;0&#x27; and keep going until I get to &#x27;12&#x27;. Even though there are 13 items in my array?<p>I see.<p>zero-indexing is good for system-level stuff, for dealing with actual memory and so on, but I&#x27;m still not convinced it&#x27;s the right way. It&#x27;s certainly not the one true way, 1-based indexing is completely valid for some use-cases like maths.<p>Either way, there will be off-by-one difficulties, either in ordinals or count or whatever, so it&#x27;s a trade-off.

Once you flatten multidimensional arrays the folly of starting at 1 becomes apparent (much like mathematics got so much simpler when we switched to logarithms with the &quot;obvious&quot; log a + log b = log ab which was a breakthrough at the time).<p>If you have a two dimensional array A (1..N X 1..M), then flattening it becomes A[i][j] = flat[i + (j-1) * N]<p>Continuing to higher dimensions it only gets uglier.<p>0-based arrays are far simpler. When flattening A (0..N-1 X 0..M-1) A[i][j] becomes flat[i + N * j].<p>It&#x27;s completely analogous to how our base-10 positional system works. Each digit doesn&#x27;t start at 1, they start at 0, which is why 237 is just 2*10^2 + 3*10^1 + 7*10^0.<p>ADD: TIL HN supports escaping the astrix.

I understand this as follows:<p>If directly accessing byte-addressable memory, the command, &#x27;go to address 0xff and get me the data stored in the ten bytes beginning at 0xff&#x27; will return data at 0xff + 0, 0xff + 1, ..., 0xff + 9. Hence counting should start at zero, with the zeroth byte. Describing this sequence as range(0, 10) is convenient since 10 - 0 gives us the count of bytes in the sequence.<p>If accessing objects in an linear data structure via an interface, at a higher level of abstraction, then a natural choice is to label the objects starting with one, i.e. get the 1st object&#x27;s data, get the 2nd object&#x27;s data, ..., get the 10th objects&#x27;s data. Note, range(1, 11) still works as 11 - 1 gives us the total object count. (Python seems to get this right in both cases, i.e (inclusive, exclusive)).<p>However, if one is also using low-level byte-addressable memory at the same time, this can get unnecessarily confusing, so it&#x27;s probably simpler to just always count starting at zero, for consistency&#x27;s sake - unless you&#x27;re writing a user interface for people who&#x27;ve been trained to start with one?

If I have some apples on a table and pick single apple up, I don’t have zero apples in my hand. I think that’s why numbering doesn’t start at zero.

I always found array index confusing.<p>For example, given a array with size N in Python, we can iterate it from 0 to N-1 (onwards) and from -1 to -N (backwards), which is not consistent at all.<p>Programming language is meant for human eyes. It would be better if array index being 1 to N, and let the compiler substract that 1 for us.

He’s not wrong, but ask any normal person “What’s the first thing on this list” and see what happens…

The part where he asserts indexing should start at zero is this:<p>&gt; Adhering to convention a) yields, when starting with subscript 1, the subscript range 1 ≤ i &lt; N+1; starting with 0, however, gives the nicer range 0 ≤ i &lt; N. So let us let our ordinals start at zero: an element&#x27;s ordinal (subscript) equals the number of elements preceding it in the sequence.<p>&quot;A nicer range.&quot; This is just Dijkstra&#x27;s preference.<p>Interestingly, he links ordinals (the subscript) to cardinals (how many numbers there are before the element).<p>The off by one is just as likely in both schemes with half open intervals.<p>The nice property of the length of the sequence falling &quot;for free&quot; from the indices is not essential if you track the length separately. While it was important in the age of machines with severely constrained memories, the downsides outweigh the merits.

I think about it as a difference between indexes and offsets.<p>C uses pointer offsets. Base pointer + offset = destination address. C &quot;array&quot; syntax is sugar for this addition. There are no array indices in C, just pointer offsets. Thus, they start at 0.<p>Some languages have arrays that aren&#x27;t just a pointer to the first element. In those, indices are a better option. There, starting at 1 usually makes more sense.<p>The first number used should match the use of that number.

I don&#x27;t know about arrays, but numbering floors starting from 1 is absurd.<p>In most of Europe ground floor is 0, underground floors are negative, floors above the ground are positive numbers.<p>Integers were invented for a reason, use them :)

Wouldn’t 2..12 =&gt; 2 &lt;= i &lt;= 12 be the most readable version? Why “&lt; 13”?

Unfortunately most of the world disagrees

Obligatory remark when this is referenced that it was specifically wrong about FORTRAN when written. As of FORTRAN77 you could index arrays as you like -- bounds of any integer -- potentially differently in different parts of the program.