Talk:Zero-based numbering

There is no such thing as "zero based indexing"

The article itself spells out the cause of the argument and the solution. "Referencing memory by an address and an offset... In this context using "zeroth" as an ordinal is not correct".

In computer languages we don't specify an index, we specify the 'offset' from the first index. These are very different things. An offset of zero does not make the first element the zeroth element. There is no such thing and there will never be a zeroth element. This is a perpetual mix-up of terminology.

The misleading math derivative example at the start finally makes since. A zero modifier on the first function returns the first function itself.

So languages are either "index based indexing" eg MatLab, Fortran or "offset based indexing". It is simply incorrect to say "zero based indexing".

It is like saying the "dark side of the moon". Most people know that we mean far side from earth but it is still and incorrect and misleading phrase that people should stop using.

BCPL anecdote

I find the BCPL anecdote misleading, not only have I have multiple multiple different versions of it, but it misquotes both Hoye and Stevens. The bit about the 7094 was not something Stevens said, it was Mike's speculation based on a separate document, and the indirection operation in BCPL was always at run-time because it was completely beyond the state of the art in compiler technology in the early '60s to track which words used in indirection were safe to optimize in the way he suggests.

BCPL arrays were zero-origin because it fell naturally out of the unification of pointers and other values in a low level language. Stevens says as much in the comment Mike quotes:

As for BCPL and C subscripts starting at zero. BCPL was essentially designed as typeless language close to machine code. Just as in machine code registers are typically all the same size and contain values that represent almost anything, such as integers, machine addresses, truth values, characters, etc. BCPL has typeless variables just like machine registers capable of representing anything. If a BCPL variable represents a pointer, it points to one or more consecutive words of memory. These words are the same size as BCPL variables. Just as machine code allows address arithmetic so does BCPL, so if p is a pointer p+1 is a pointer to the next word after the one p points to. Naturally p+0 has the same value as p. The monodic indirection operator ! takes a pointer as it’s argument and returns the contents of the word pointed to. If v is a pointer !(v+I) will access the word pointed to by v+I. As I varies from zero upwards we access consecutive locations starting at the one pointed to by v when I is zero. The dyadic version of ! is defined so that v!i = !(v+I). v!i behaves like a subscripted expression with v being a one dimensional array and I being an integer subscript. It is entirely natural for the first element of the array to have subscript zero. C copied BCPL’s approach using * for monodic ! and [ ] for array subscription. Note that, in BCPL v!5 = !(v+5) = !(5+v) = 5!v. The same happens in C, v[5] = 5[v]. I can see no sensible reason why the first element of a BCPL array should have subscript one. Note that 5!v is rather like a field selector accessing a field in a structure pointed to by v.

— Richard Stephens

But the speculation about performance considerations on the 7094, and especially the idea that it was precalculating indirection at compile time, are not supported by the original documentation. When you allocate a vector in BCPL, like "LET V = VEC 5", you actually allocated 6 words, the first of which contained the address of the second. Most if not all of the time you *created* it on the stack, at runtime. You could freely initialize words with addresses calculated at runtime, such as this example taken from the BCPL manual:

LET IOV = VEC 650
LET IOVP, IOVT = IOV, IOV + 650