Why do arrays start at 0? | Hacker News Reader

Why do arrays start at 0?

buttondown.email

413 pointssnikolaev674 comments

I don't quite understand the argument "0-based being easier for pointer arithmetic is nonsense because the language doesn't have pointers".

Whether or not the language presents the concept of "pointer" to the user is independent of whether or not it uses pointers internally. And if it exposes arrays as a concept, it has to implement them somehow.

The simplest possible implementation of arrays is having a start address and putting all elements next to each other in RAM. To get the address of a particular item, this layout naturally leads to the formula "base address + index * element size", with "index" being 0-based. If you want to expose other indexing schemes in your language, you'll have to add more logic to convert the user-visible index back to 0-based before you can obtain the address.

All of this is completely independent of the fact whether your language exposes pointers to the user or not.

Even the yacht story sort of hints at this:

> To keep people from having their jobs cut short by yacht-racing, Richards designed the language to compile as fast as possible. One optimization was setting arrays to start at 0.

If all indexing schemes were equal, why would this change even be an optimisation in the first place?

The "language" that has a 0-based indexing scheme is assembly. An HLL with 1-based counting that compiles to assembly will introduce additional computational overhead for the translation of the index.

If 1-based indexing was used in assembly, then "mov 1(%ebx),%eax" would be the equivalent of "mov (%ebx),%eax".

> additional computational overhead

at compile time, not runtime.

> An HLL with 1-based counting that compiles to assembly will introduce additional computational overhead for the translation of the index

Not necessarily so for translation of an index that is evaluated at run time. PL1 (back in the 1960's) compiled arrays into 'dope vectors'. Each array's dope vector included highest and lowest valid subscripts for each dimension of the array and the address where the element with all zero subscripts would be found, if it existed.

Not sure if assembly/machine code is that relevant. If one based indexing was more prevalent, the LEA instruction on x86 would just subtract one during execution

I would be fine with it all if 0-based was called "offset", with "index" reserved for 1-based.

The element at offset 0 is the first element.

Precision in naming is important.

Defining index as the element wise offset is a precise well formed definition/name.

It's also a definition commonly used in math, through not always. It depends a lot of the area of mathematics and even the cultural context.

The only reason we sometimes feel 0-index is wrong IMHO is because the english language describes entities in a sequence as 1st, 2nd, 3rd etc.

But I wouldn't be surprised if there is some human language somewhere which does it differently. Like something which roughly matches to english like "head, head+1, head+2, ...".

But we'd have to change all the "i"s in our for loops with "o"s across the planet, maybe even beyond. I'm willing to help, whatever it takes.

> Precision in naming is important.

It really isn't. The human race gets by without it the vast majority of the time.

That so people in this thread argue about the higher-level language (missing the point) shows that few people found access to the underlying machine code.

Which is sad, because all code is still executed as machine instructions even when the developer does not see it or does not want to care.

We're 20 years past the point where you can expect everyone in tech to trace every instruction down to machine instructions. Higher level languages abstract away the need for it, and for the most part, we can rely on the authors of those languages to make many of the decisions that impact performance. The rest of us learn about these details on posts like this. It's not a sad fact, in fact it's probably one of the most useful things that's happened in tech. It frees people to think about other problems.

If this were the primary reason, it seems odd that some of the earliest popular languages used 1-based indexing in an era with much slower CPUs (<= 1 MIPS) and less available memory to store instruction code. If the authors of FORTRAN were comfortable with 1-indexing on the IBM 704 (40 KIPS) in 1957, it couldn't have been prohibitive. At the same time, as computer use cases became more interactive there may have been a greater focus on performance, but it likely that the semantics of the high-level language were at least as important.

“machine code” isn't really the zero point that's special nowadays.

The code the programmer wrote is compiled to something such as LLVM IR, LLVM IR is further compiled by LLVM to Assembly, this is further compiled by an assembler into machine code, and then the c.p.u. further compiles this to it's internal code as it executes it. “machine code” really is no more special in this chain of events than, say, LLVM IR.

It was just most basic example. Indices are connected with math all the time. Consider implementing circular queues with 1-based arrays. Any arguments about what’s _possible_ miss the point. Arguments about what _feels_ natural purport to know the human mind which I find generally suspect. Mostly I think of computers as tools and am interested in getting the most functionality out as smoothly as possible not as slaves whose job it is to make my life worry free.

> To get the address of a particular item, this layout naturally leads to the formula "base address + index * element size", with "index" being 0-based. If you want to expose other indexing schemes in your language, you'll have to add more logic to convert the user-visible index back to 0-based before you can obtain the address.

The easy way to do that is by shifting the base address. In pseudo-C (I think that computing the b pointer is non-conforming, even if the code never tries to access b[0], but compilers can do this without problems):

   int a[100];      // array of 100 integers, zero-based
   int * b = a - 1; // array of 100 integers, one-based

Things only get costly when you want to check array bounds or when you have multi-dimensional arrays. There also may be non-standard architectures where this kind of stuff isn’t possible.

In this case, b is a pointer that does not point to a valid address. You can't memset(b, 0, 100), or do any of the other regular pointer things with b.

It feels like you're introducing a million edge cases.

Okay, now do 2D arrays.

This is undefined behaviour, as a pointer is only allowed to point to valid addresses (as well as the index of the last element + 1, but it can't be dereferenced).

Should work 99.99999% of the time until someone tries to put an array at 0x000001 :)

Amusing but probably irrelevant: the sailing yacht racing handicapping calculations mentioned are almost certainly under the Performance Handicap Racing Fleet (PHRF) system[0]. This system is "zero based" in its own way. A sailboat's performance is assessed and handicapped against a standard yacht with a zero rating. Your time to complete the race course is adjusted by your handicap to determine your final standing. This lets you race slower and faster types of boats in a "fair" way.

[0] https://en.wikipedia.org/wiki/Performance_Handicap_Racing_Fl....

Implementation matters for performance, but even beyond that, the interface matters for users. 0-based offsets are convenient for users doing math on indexes.

A pointer is just one kind of array-like indexing scheme. Good pointery languages will distinguish Address from Offset from Integer.

Nats start at 0, end of discussion - it's only logical to index by the naturals.

That's really silly - the natural numbers also famously start at either 0 or 1, depending on the country, the discipline, and the individual.

If there were any justice in the world, they'd start at 2, as a handicap. They might even make it out of the bottom of the NL east if that was the case.

> Nats start at 0, end of discussion - it's only logical to index by the naturals.

Now you'll just bring out the people who start the naturals at 1.

other important and day to day tools like rulers, clocks and speedometers also start at zero. So it's not exactly "bending humans to microprocessors weird alien ways".

It all makes perfect sense in the context of measuring.

> Nats start at 0, end of discussion - it's only logical to index by the naturals.

Well, no, obviously you want to index by ordinals, and they start at "first".

Where 0 is the cardinality of the empty set, i.e. some empty collection. Not a convincing argument.

I learned them in elementary school (in the US) as starting at 1. Indeed, Google's first result for natural number is from Oxford Languages, and defines natural number as:

the positive integers (whole numbers) 1, 2, 3, etc., and sometimes zero as well.

Waste 0th element or reuse it for something like length (hello, pascal strings). Another option is using base_address - element_size as your array value. Another option is using +element_size for all array accesses, assembly languages usually have this instruction. There’re many options to use 1-based indexing without sacrificing performance.

> assembly languages usually have this instruction

Is that so? I wasn't aware of that.

newer pascal strings are #0 terminated, original pascal strings were 255 chars max with string[0] being the string length, they were also not Unicode friendly, newer pascal compilers still support this as the shortstring type. I use pascal style strings in my embedded C library I wrote in 1989 much more efficient on 8/16-bit systems

This is far easier and clearer than the entire article. Good stuff.

0 for offsets, 1 for ordinals, that's usually the rule. Of course, both are conventions.

I always assumed it started at zero otherwise you don’t use the full range of an unsigned integer and you can only have an odd number as your capacity (for whatever you use indexing for, not just RAM addressing).

Other advantages of zero based indexing, beyond being 'closer to the machine':

It works better with the modulo operator: `array[i%length]` vs `array[(i+length-1)%length+1]`. Or you would have to define a modulo-like operator that maps ℕ to [1..n].

It works better if you have a multi-dimensional index, for example the pixels in an image. With 0 based indexing, pixel `(x,y)` is at `array[x+widthy]`. With 1 based indexing it is at `array[x+width(y-1)]`. You might argue that programming languages should support multi-dimensional arrays, but you still need operations like resizing, views, etc.

Another advantage is with ranges: 0-based indexing and exclusive ranges work well. This is apparent with cursor position in text selection

Consider:

    Characters       h e l l o
    Cursor index    0 1 2 3 4 5
    Char index       0 1 2 3 4
    Range [0,3)     [0,1,2]
    Range [2,5)         [2,3,4]
    Range [1,1)       []

If we used 1-based indexing and exclusive ranges, it leads to ranges where the end index is greater than the string's length...

    Characters       h e l l o
    Cursor index    0 1 2 3 4 5
    Char index       1 2 3 4 5
    Range [1,4)     [1,2,3]
    Range [3,6) (!)     [3,4,5]
    Range [2,2)       []

but if we use inclusive ranges, it leads to ranges where the end index is less than the start index...

    Characters       h e l l o
    Cursor index    0 1 2 3 4 5
    Char index       1 2 3 4 5
    Range [1,3]     [1,2,3]
    Range [3,5]         [3,4,5]
    Range [2,1) (!)   []

Also:

    Characters            h e l l o
    Cursor index         0 1 2 3 4 5
    0-based range [0,3)  [0,1,2]
    1-based range [1,4)  [1,2,3]

for the 0-based range [0, 3), the left array bracket is at cursor index 0, and the right bracket is at index 3. With 1-based indexing it doesn't work like that because the range is [1, 4)

This is the bane of my existence working with Lua.

Iterating an array or adding to the end are fine, we have ipairs and insert for that, but ranges on strings I'm constantly having to think harder and write more code than necessary.

I love the language, wouldn't trade it for another, but the 1-based indexing on strings, which represents an empty string at position 3 as (3,2), it's egregious.

Not as egregious as a dynamic language where 0 is false though.

Yeah, offsets are just easier to mathematically manipulate than ordinals. It's not just pointer arithmetic where it matters that item i corresponds to start+i*step. Any time you want to convert between integer indices and general linearly-spaced values, 0-based indexing is more convenient.

In many domains code maintenance is more important than hardware costs. In many domains 1-based indexing is a better fit, meaning less conversion code, meaning simpler code. Thus, the best indexing choice depends on the domain and circumstances, as do many controversial questions. Most tend to specialize in specific kinds of domains and over-extrapolate their experience into other domains.

I'd agree so why did languages that allow specifying the base die (other than maybe VBA).

A disadvantage comes to mind. While the following loop works as expected:

    for (size_t i = 0; i < length; i++) ...

The following causes an unsigned integer underflow and is an infinite loop:

    for (size_t i = length - 1; i >= 0; i--) ...

As Jens Gustedt points out[1], the following intentional unsigned overflow works perfectly for downwards iteration (even when length is 0 or SIZE_MAX), though it looks a bit confusing at first:

  for (size_t i = length - 1; i < length; i--) ...

You are also free to start at any other (not necessarily in-bounds) index, just like with ascending iteration.

[1] https://gustedt.wordpress.com/2013/07/15/a-praise-of-size_t-...

In that specific case I'd do the following:

    for (size_t i = n; i-- > 0 ;) ...

Or count from `length` to 1, but subtract 1 in the loop body, or count up and subtract the length in the loop body. Any modern compiler should be able to optimise these to be equivalent.

In the majority of cases, counting down is not necessarily. Nor is ordered iteration. Most languages have a `for each` style syntax that's preferable anyway.

the correct way/idiom to reverse iterate an array is

  for (size_t i = length; i-- > 0; )...

It's surprising how often the issue pops, it works well with both signed and unsigned integers.

(edit) I've started with one based indexing (basic)... mixed with 0 based (assembly), more 1 based (pascal), then more stuff (all zero based). I am, yet, to see a real advantage of a one based indexing... after the initial process.

In the C programming language unsigned integers do not overflow. They wrap. This is well-defined behaviour and the example code is simply incorrect. Most modern compilers will give you a diagnostic for this.

If you have foolishly turned off -W in your build system, that could happen. Otherwise, you get a nice warning pointing out your folly.

Unless wrapping underflow is sensible for the domain (which it isn’t when representing the size of something), unsigned integers are usually a bad idea.

You can always rip a page out of C++’s playbook:

    for (size_t i = length; i > 0; i--) {
        // ...
        item = array[i - 1];

(This is how reverse iterators work in C++.)

  for (size_t i = 0; i < length; i++) {
      size_t j = (length - 1) - i;
      ...
  }

EDIT: change i to j

A rare case where 1-based indexing is more convenient is complete binary trees laid out breadth-first (as in a standard binary heap): parent is i div 2 and children are 2i and 2i+1 when starting at one and who knows what when starting at zero. But that’s the only one I know.

Except 1-based indexing is what we use in normal language. We don't use "zeroeth" or "player (number) zero" etc. And the word "first" is shortened to 1st etc. Personally I think we'd be better off if programming languages stuck to the same convention - off-by-1 errors aren't the hardest problems to deal with but they're still annoying.

With 0-based indexing the children are at 2i+1 and 2i+2. The parent is at (i-1) div 2.

Not hard to figure out.

An incredibly unrare case happens all the time in my work: array[length - 1], or variations of this. Anything involving the last element of the array, and often iterating through the whole array will use something similar at some point.

This is the reason I always think of when I hear the question

I think the 1-indexing folks would have to argue that a%b should return a value from 1 to b inclusive. This does make the same sort of intuitive sense as 1-indexing. For example we number clocks from 1 to 12.

% is defined as (mostly) a remainder operator. I don't think you want to change the semantics of division itself.

But interestingly, the number at the top is 12, not 1.

No we don't. Clocks start at 0. what time is it when it's half an hour after midnight? 00:30.

12 is zero, in 12-hour clocks.

Because otherwise you would be wasting a perfectly good number for no reason, which means you need to use more bits to do the same thing.

To write 4 numbers (including zero) you only need two bits

To write 4 numbers if you avoid using the number zero, you need three bits

If you extrapolate that a little bit, you'll realize that you'll need two bytes (1 Byte + 1 bit from another byte) to store the indices of an array with 2^8 elements, which is just dumb.

Some of you might be thinking: you don't need to store it the same way it's written, you can just substract 1 from whatever the user typed and convert it behind the scenes.

Yes, you could subtract 1, but then you would be making the whole system more complex, opaque, and unelegant, while hiding information from the programmer for no good reason.

The same applies to counting in other bases too. For instance, in 1-indexed counting grids for kids, the last column always feels out of place.

0-indexed decimal grid:

   0  1  2  3  4  5  6  7  8  9
  10 11 12 13 14 15 16 17 18 19
  20 21 22 23 24 25 26 27 28 29
  30 31 32 33 34 35 36 37 38 39
  40 41 42 43 44 45 46 47 48 49
  50 51 52 53 54 55 56 57 58 59
  60 61 62 63 64 65 66 67 68 69
  70 71 72 73 74 75 76 77 78 79
  80 81 82 83 84 85 86 87 88 89
  90 91 92 93 94 95 96 97 98 99

1-indexed decimal grid:

  1  2  3  4  5  6  7  8  9  10
 11 12 13 14 15 16 17 18 19  20
 21 22 23 24 25 26 27 28 29  30
 31 32 33 34 35 36 37 38 39  40
 41 42 43 44 45 46 47 48 49  50
 51 52 53 54 55 56 57 58 59  60
 61 62 63 64 65 66 67 68 69  70
 71 72 73 74 75 76 77 78 79  80
 81 82 83 84 85 86 87 88 89  90
 91 92 93 94 95 96 97 98 99 100

Are you sure it doesn't just look that way because you are used to monospaced fonts? Ask a kid to show you their zeroth finger.

Neither looks like the canonical choice to me. They are both just as good.

counting grid? What even are these?

Yeah, but then couldn't the compiler just swap the 1 with a 0 and 256 with 255?

That gets really dicey if you're storing the value of the index in a variable. Does the programmer need to know that if it's an INDEX they're storing that goes from 1-256 they can fit that into an 8-bit value because the compiler will magic away that last bit? Speaking of which, how will the compiler know which 1's are really 0's and which 256's are really 255's? Will it compile that 1+1=1 if I use that result as an index? Just having a 0th index is much simpler than all of that noise.

Someone linked to your johnny decimal system earlier today. https://johnnydecimal.com/ I liked the idea but I noticed that it didn’t seem to be 0 indexed. If I adopt this i’m definitely going for zero indexing.

Zero is reserved for meta stuff: https://johnnydecimal.com/concepts/what-about-00-09/

You could have a 1 based type that doesn’t include 0. Or make zero the max value.

Fron the article:

> It's not the reason you think. No, it's not that reason either.

Indexing is a language level concern, it has nothing to do with the generated code.

Unless you write machine code I guess.

> Indexing is a language level concern

IIRC, Visual Basic 6 took a why not both? approach to array indexing.

I like how the article summarizes this idea:

> These all point to one reason why 0-indexing might be preferred: it matches machine semantics more

But then of course the reason why 1-indexing is better (or really, arbitrary indexing, which is even better) is that it matches human semantics better.

Edsger Dijkstra wrote an interesting article titled 'why numbering should start at 0'. Perhaps not answering the question directly but an interesting read nonetheless.

https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...

As the article implies, Dijkstra was specifically wrong about FORTRAN, as defined at the time — the '77 standard, when it was still only conscionable to SHOUT 6 alphamerics.

“… you probably know that arrogance in computer science is measured in nano-Dijkstras.” — Alan Kay

"This quote keeps on showing up out of context." — Alan Kay https://news.ycombinator.com/item?id=11799963

I've never understood the first half of Dijkstra's argument. Unless we are programming a theoretical Turing machine, there will also be a maximum number that can be represented, so the argument about using inclusive bounds for the lower end also applies to the the upper end. So you can't represent all numbers with a single range style. You either end up excluding the smallest number, the largest number, or the empty set. Or you need special notation to handle one of those three cases.

I suppose the 0,1,infinity principle argues that including the empty set and smallest number is more important that including the largest number, so that notation should be preferred by default. And when writing using A<=i<B it is clear enough, but once you remove those symbols and start using them in indexing or function call syntax, like [A:B] or range(A,B), the inconsistency of bounds really breaks my brain, and having to pass a number larger than the largest array index as an upper index range bound gives me nervous ticks. I'd rather use inclusive bounds everywhere and have special syntax for empty set.

Sure but it’s much more common for a range to include 0 than INT_MAX

Interestingly, that Dijkstra article was originally published/circulated in handwritten form. It helps showcase the author's handwriting skills.

https://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF

The handwriting skills were common back in the day... By the way, are you sure that it was Dijkstra himself who handprinted these texts (rather than have, say, his secretary do that)? Because this is not exactly the (beautiful) handwriting as it was taught back then.

If you ask people which floor of building they're on, it's going to depend on which country they're in. In North America, at least, the first floor you walk into (in a sane city: I understand there are some which do not qualify in this respect due to hills or historic disaster recovery) is the first floor. On other continents, you enter the ground floor and need to take stairs or an elevating device to get to the first floor.

"Natural" zero-based counting at its best.

A big international corporation (Siemens) had, at one point, standardized their buildings world wide to have room numbers starting with 2 on the ground floor, 3 on the floor above etc., leaving space for two basements.

All room numbers were 5 digits, and skipped numbers if there were multiple windows in one room, based on the theory that such a room might later be sub-divided, and wanting to avoid renumbering of rooms down the hallway.

(I encountered this around 2003, so might have well changed since then; didn't find any references only with a quick search).

I worked for them relatively recently and didn't encounter this; or at least never noticed. Then again, our office building was an open office plan where desks next to the windows and rooms (conference or office) were all in the center of each floor.

The ground floor is 0. The floor above 0 is 1. The floor below 0 is -1. Anything else is crazy TBH, the whole point of integer numbers is to count things that start at a defined point and go opposite ways. Why shift it and then reinvent weird pseudo-negative numbers like S1?

But then again people measure distance in feet and write dates as month day year :)

It would be nice if this was the case. In grad school I taught in a building that was on a hill and had once been separate buildings so different entrances were on different floor and the transition between the former separate buildings was 4 stairs.

So there was a floor with rooms numbered 1xx and 0xx. There was also a floor below the 0xx floor. They just numbered it 00xx. And you could enter the building on any of those floors depending on what door you picked.

The class I taught was in 0005. Room 005 was someone's office. So on the first day of every semester we would have students waiting outside the door of 005 instead of 0005...

Counterpoint: because floors are sum types.

Floors 1 through 10 are "regular" floors. L is the lobby. P1 through P3 are the parking (basement) levels.

So you have three types: regular, lobby, and parking. And the elevator labels are of type regular | lobby | parking.

(Now you can't disagree with me because sum types are popular on HN, and I have framed this in terms of sum types.)

We have a building at the local university that has ground at one end level with transitory step between floors -1 and 0, you enter the building through the stair well, and descend or ascend to get to a floor. I wouldn't be surprised if an architect designed a building that did this on flat ground, violating the ability to number floors relative to ground with integers.

This is how it should be, but the only country in the world, AFAIK, that does it that way is Germany.

When I was at Leeds University the ground floor of the Physics Admin building was Level 6 (it went up to Level 11). It was built on a hill and according to legend this allowed room for expansion (which never happened) down the hill without requiring negative floor numbers.

To add to the fun the only continuous corridor through the entire T-shaped building was on Level 10, one end of which (the base of the T) was at ground level on its part of the hill. There was a famous 'kink' in the middle of the top / cross-bar of the T (apparently the longest corridor in Europe) because they started building from each end and were slightly off.

I always said it was an argument between the counting of things versus the relative offset of things.

This is a great example.

I call `array[0]` the first element. I don't know what you'll think of that.

I wonder how many multiples of people who like arguing about starting from 1 vs 0 and how many people were confused for more than a day

The Patterson Building at Acadia University in Wolfville, NS, has a basement and four floors. The rooms on the first floor are numbered 1XX, second floor 2XX, etc. up to the top floor 4XX.

The elevator, however, goes from floor '1' (the basement), to floor '5' (the top or fourth floor).

This really confuses visitors.

The Elevator Mafia want $10,000 to fix it.

I've been living in North America for decades. Every building has G (zero). This is the floor that you walk into and has a lobby. The next floor up is 1 as such is labeled in the elevator.

So your initial assumption is incorrect from my experience.

A lot of elevators in US do indeed have G for the ground floor, but that's because they are made by ThyssenKrupp AG, a German company ;).

This is not my experience in the US. Most places either have G or 1 for the first floor. Then 2 for the next. So some elevators say G, then 2, 3, and so on.

I've seen setups like you mention, but they definitely aren't the majority in places I've lived.

What city are you in, out of curiosity?

It really comes down to a choice between a machine-focused (0) or human-focused (1) approach.

The 0 makes a lot of sense in a C pointer world where memcpy and other alike functions can be written very thight.

The 1 makes a lot of sense in a human world, when we count, we start at 1, we talk about the "1st", counting on finger starts with 1, etc.

I once were at a Lua (1 indexed language) conference where this was discussed, and Luis started explaining why Lua was 1-index with this sentence: "The 1st argument ...." :)

> It really comes down to a choice between a machine-focused (0) or human-focused (1) approach.

Just think of 0-based as offset-based and 1-based as index-based. Both are intuitive just like that. I never get why people arguing over this bring pointers and memory (or anything computer related) to the table. No normal person is going to understand that, but everyone understands that if you don't move at all (0 offset) you stay at the first (index 1) item. Add one and ... you get the point.

> when we count, we start at 1, we talk about the "1st"

Although often with an implicit zero. Under typical North American culture, your 1st birthday, for example, is more accurately the first anniversary of your birthday. Your birth is zero indexed.

> human-focused (1) approach.

TBH humans would have been better of if we were 0-based, it's just a convention. And we have the confusing language where "20th century" means 1900's. If we wanted to bring the 1-indexing we use in language to the fullest extent here to fix that particular issue, time counting would have to start at 1111. Except that won't work once reaching 5-digit years.

If we would start with "zeroeth" instead of "1st", then this would have solved itself and 20th century would mean 20xx's.

I especially don't understand why mathematicians use 1-based indexing (for matrix rows/columns etc...). Like programmers, they should see the advantages of starting at 0 (e.g. the coordinates of subdividing into block matrices are simpler if starting at 0). Mathematicians do start at 0 for the origin of plots, after all.

> The 1 makes a lot of sense in a human world, when we count, we start at 1, we talk about the "1st", counting on finger starts with 1, etc.

It is more like counting from 1 is just a leftover from times where zero was not commonly considered as number. Once one have zero, it makes sense to use it as an initial ordinal (see e.g. set theory, where zero is both initial ordinal and initial cardinal number, way before computers).

Another example is time and date, we start counting of days from 1, but counting of hours (at least in 24-hour notation) and minutes from 0.

> Luis started explaining why Lua was 1-index with this sentence: "The 1st argument ...."

Note that for spoken language, it is "The first argument ..." and 'first' is etymologically unrelated to 'one', but related to 'foremost', 'front', so it make sense to use 'first' for the initial item in the sequence even when using counting from 0.

In Western music theory, intervals are one based. No pitch change is "unison"; one diatonic step is a "major second" and so on. As a result of this silly state of affairs, an octave occurs every 7 notes, even though the root "oct" means eight. Furthermore, a "rule of nines" is needed to invert an interval: e.g. inversion of minor 3rd is a major 6th (exchange major/minor, subtract from 9).

I don't think 1-based arrays are better notation, even completely ignoring that code has to run on a machine.

99% of the times, the correct approach is to use iterators. When you really need indices (and you almost never do), 0 is more practical, because it matches the "including start, not including end" convention.

> when we count, we start at 1

That is false; counting begins by initializing an accumulator to zero. When you register the first item, the count jumps from 0 to 1.

> when we count, we start at 1

If I ask you to count the number of red balls in a bag with only 3 yellow balls, then the initial count in your head is 0, you inspect the balls one by one, never encountering a red ball, and thus never incrementing the count. And then you pronounce your final count of 0. So that's counting starting from 0.

What you call "starting at 1" is not so much the start as it is the first increment, which need not arise.

> human-focused (1) approach.

If we would start with "zeroeth" instead of "1st", then this would have solved itself and 20th century would mean 20xx's.

I have used 1 based in basic/pascal and 0 based (well in pretty much everything), 0 based effectively no off-by one mistakes. 1 based - common. Most idioms - incl. forward and reverse iterations work better, and are easier to remember with inclusive/exclusive pattern

Other than that - binary AND and power of 2 sized arrays are the backbone of any hashtable. Overall modulus (binary AND) is actually useful.

It has nothing to do with pointers and everything to do with basic computer arithmetic. You can constrain the range of an integer with a bitwise AND operation providing a cheap modulus by power of two. In this regime, zero-based indexing is the natural result. You have to make an adjustment for 1-based. There are whole host of other operations that are simpler with 0-based indexing.

The problem it that most people, even programmers, don't understand how computer arithmetic works and have fantasies of mathematical number lines that the hardware only partially simulates. You see this consistently in the post-Java crowd who think that unsigned integers are some sort of unholy aberration because the languages they've grown up went further to maintain the fictional number line semantics.

Human makes a lot of inconsistent thing: We usually think the 1st floor, and the basement as 1st underground floor ( -1), but the floor jumps from 1 to -1!

Also, the time jump from 11AM to 12PM to 1PM! So I think more human friendly sometimes means more confusing.

Is it machine-focused that we can convert a distance of 1.5 m to 150 cm just by multiplying by 100?

Maybe distances should be human-focused, so that no displacement is equivalently expressed as 1 cm, 1 m, 1 km, ...

Then converting a distance d from m to cm is (d - 1) x 100 + 1.

I believe there's a powerful status quo bias.

Doing the reversal test, if programming languages had all been 1-indexed, then I doubt we'd hear much from people, in 2022, saying "I think the first element should be 0, and the second 1".

> The 1 makes a lot of sense in a human world, when we count, we start at 1

As a kid I learned "one one-thousand, two one-thousand, three one-thousand" when counting time out loud, but at some point I realized this was incorrect. The prefix is the start of the nth second but it isn't complete yet, so for example stopping in the middle of saying "two one-thousand" you actually haven't reached two seconds yet.

My fix was to move the prefix to the end, so I say "one-thousand one, one-thousand two, one-thousand three".

In retrospect maybe I should have used "zero one-thousand, one one-thousand, two one-thousand".

Ah, yes. Cardinal numbers and ordinal numbers both end in the word "numbers" so they're the same thing. No need to distinguish between having three apples and having the third apple.

Yes, but "human-focused" 1-based indexing comes at a cost since at the end of the day the CPU has to add (index * element-size) to the array base address to get the address of the indexed element. With a 1-based index there's additional overhead in either having to subtract 1 from the index or to have a wasted "element 0" to avoid the need to do that.

There are a lot of cases where a zero index makes sense. In physics and math there are cases where you start the index at 0 and others where you start at 1. And even some where you start at -1. Which you use depends on what is most convenient for the problem at hand.

At which number starts the first centimeter on a ruler ?

I always thought of the machine focus being that the location of the first element was the location of the array plus zero.

If you think of the index as an offset you would start with 0.

BTW on which level is the 1st floor?

There were a number of systems oriented languages that, while algol-like in syntax, used zero-based array indexing, predating C. BCPL was intended to be a generic systems oriented language, but Burroughs had ESPOL for their mainframe architecture, and HP wrote their operating systems and compilers in SPL, which was specific to their stack-oriented HP3000 architecture. All these used zero-based indexing, because for low-level, memory conscious manipulations, it's much more natural than one-based. But nothing is universal, and IBM's systems oriented languages (BPL, PL/S, and PLS/II) were more an evolution of IBM assembler and then Wirth and PASCAL, and used one-based array indexing.

Personally, I've always found zero-based more intuitive and satisfying, absent arbitrary indexing (in which case I'd chose zero-based for most purposes where there wasn't a compelling solution based reason to use a different index base). But then spent years writing SPL ... I

On a cursory look, I'd say one based is more intuitive, for the sole fact that the a[len(a)] is the last element. Actually I remember there was a small time when I started programming in assembly it took me a while to get used to reasoning about the end of the array.

much of intuition is made, not innate, at least for things as abstract and arbitrary as languages and notation. If you come at this question from a point of view where an array is a block of memory words indexed by a pointer - which is pretty much how system programmers back in the day when I did such things, 50 years ago - then zero based seems natural and obvious. The pointer to the array is the array, and the first element in the array is the pointer plus zero, the second, the pointer plus one, and so on. Once you start thinking that way. For multi-dimensions, the arithmetic just falls out as well.

But I don't think the fact that many of us developed that intuition, makes it inherently better. It just makes it more intuitive for those of us who developed that inuition. I've written oodles of codes with both paradigms. Either works. Zero is just more natural, to me.

Unusually for me, I read TFA first. Immediately thought "this is all wrong", then realized 400 commenters had posted the same thing already.

I have Martin Richards book on my shelf, and for a while shared an office with his coworker. I'm also one of the few folks here who has coded in BCPL.

Ok, so that said, this article is obvious nonsense. Zero indexing comes from the CPU itself. It's how you generate an indirect address by adding the offset. Many CPUs have this in hardware. They don't support non-zero offsets. The reason some languages have zero-based indexes is that their developers had the mind set of doing the same thing you do when writing machine code. They probably also wanted to directly interface between their language and libraries written in assembler (and the kernel was typically written in assembler too). Also they wanted to be efficient. Any offset other than zero is not efficient because you can't use the hardware addressing modes.

So then why do some languages _not_ have zero based indices? The obvious answer it that Mathematics by convention always used 1 as the base (or some arbitrary value). Many languages were conceived by mathematicians or people with a strong mathematical background.

I've discussed this a lot in real world in a different field: apartment floors. In Japan (where I live) they are 1-indexed, where the floor on the ground is number 1, while in Spain (where I am from) they are 0-indexed, where the floor on the ground is number 0.

Both have inconsistencies, like in Spain you might have a "middle ground" (entresuelo) which is neither 0 nor 1, but sits between, and is normally commercial or non-livable, reserving the 1 to the first floor where people live. I like that system better though because it usually goes 1 => 0 => -1 (underground), while in Japan you go 2 => 1 => -1, so I feel like it's missing a floor. You could justify it though as 0 being the ground line, so +1 is "the first above the floor and -1 is "the first below the floor", but I still prefer having each floor to be a natural consecutive number.

English also has that "mezzanine" concept, for partial floors with a balcony over the main floor. You see it sometimes on elevators as an M.

It seems like most newer buildings in the US and EU have "G" or "L" be the ground floor (0 / PB), and then the floor above is "1".

In older buildings, the ground floor is usually "1" - which means the floor above has to be "2".

Arrays in Ada start at the index based on the index type of the array. You can even use an enumeration type as the index:

    type Day is (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday);
    type Hours is array (Day range <>) of Natural;

    V : Hours (Monday .. Friday);

Which index type you should use depends on the problem that you're trying to model. You can find out the lower/higher end of a type/variable with the 'First and 'Last attributes.

IIRC there's an RFC though to force the lower end of the index to a certain value like 1 or any other number/enum.

Wow, I never really looked at Ada code. Been using VHDL for the past 2 years a lot and when I looked at your code I was like: 'huh strange, this looks a lot like VHDL'.

Turns out both were invented by the DoD.

>Due to the Department of Defense requiring as much of the syntax as possible to be based on Ada, in order to avoid re-inventing concepts that had already been thoroughly tested in the development of Ada,[citation needed] VHDL borrows heavily from the Ada programming language in both concept and syntax. - https://en.wikipedia.org/wiki/VHDL

Maybe I should pick up Ada soon. That could be a fun journey! (I really love writing VHDL)

I always wonder why such fundamental features were not adopted by all languages.

"Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration." -- Stan Kelly-Bootle

This comes up when giving fractional coordinates into a grid. Is (1,1) the upper-left corner of the upper-left grid box, the center, or the lower-right (or the center of the next grid box)? Alternately, is the upper-left corner of the upper-left grid box (-0.5, -0.5), (0.0, 0.0), (0.5, 0.5), or (1.0, 1.0). I've seen all four conventions used in different places, depending on whether the grid boxes themselves are numbered starting at 0 or 1, and when extended to fractional if it makes more sense to have the corner or the center of the grid box take the value of the box itself.

Worst than 0 and 1 is to have the choice. In Visual Basic 6 you have the option between the base 0 or 1 for each module. It make debugging a nightmare and you can create bug just by copy/pasting code from one program to other with a different base index.

You also have the choice in Perl, because of course, it is Perl.

The old way of doing it was setting the $[ variable to 1. You can actually set it to any value, in case you prefer to start your arrays at 42. It is now deprecated but you now have Array::Base that offers similar functionality.

Use it if you absolutely hate the person who will read your code, as if having someone read Perl code wasn't hateful enough.

One of the least-loved APL features is the fact that you can change the index origin at runtime.

My favorite example of this confusion is JS and (original) Java dates:

    > new Date()
    Wed Aug 24 2022 ...
    > new Date().getFullYear()
    2022
    > new Date().getMonth()
    7
    > new Date().getDate()
    24

So 2022-08-24 comes out as (2022, 7, 24). One-based indexing for the year and day, zero-based indexing for the month.

That comes from C’s standard library (and presumably from somewhere else before that). Classic bad design, took a very long time for people to figure out it was unhelpful and dangerous.

Dijkstra's answer (linked in the article) is best:

"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 < N+1; starting with 0, however, gives the nicer range 0 ≤ i < N. So let us let our ordinals start at zero: an element's ordinal (subscript) equals the number of elements preceding it in the sequence. And the moral of the story is that we had better regard —after all those centuries!— zero as a most natural number."

https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...

It could just as easily be 1 ≤ i ≤ N and then I wouldn't have to remember that the lower bound is inclusive and the upper exclusive.

Closed ranges (with both ends inclusive) are super annoying to work with. You can represent the empty range (unless you are willing to do [i : i-1]), and they don't compose like half open ones: [a : b) + [b : c) = [a : c).

Then the delta of both bounds (N – 1) wouldn’t equal the length of the range (N). The inclusive-exclusive convention is used in order for `end = start + length` to hold.

I don't understand why 0 ≤ i ≤ N wouldn't have worked instead, since you already have a less than or equal operator at 0.

That would give a sequence of N+1 elements, though. Confusing if you had a function like range(N), for example.

I have always assumed that is just one less operation required to resolve the absolute memory address.

The mental model of being an offset to a memory address is, I think, part of it.

I'd be surprised if the use of zero vs one actually made any difference, from a number of operations point of view -- from the compiler's point of view, the first element in the array is the first element in the array, no matter what we call it.

I mean in an extreme edge case maybe if you are computing an index, and it happens to be zero, then in your math maybe some identity related to zero could be exploited (go to element simple_integer*complicated_function(), where simple_number might be zero) but that seems a bit silly.

How would it not make a difference? If you calculate an index at runtime, to get access to the element, in 0 based would be pointer + index. In 1 based it is however pointer + index - 1 clearly there is an extra subtraction there?

In x86 you could probably hide it in the addressing but that does not mean it does not to be computed

This is primarily the actual answer. While most languages force you to see the array as an array, in C/C++ (in C++ I'm only referring to the memory allocated variable type, not an "array class") you can see it as a pointer and do your own math to address any part of it that you want. And the calculation for that memory address is idx * sizeof(the thing in your array). So the real answer here is that array semantics needed to match memory address semantics in the languages that provide that.

There's no reason why memory addresses had to start at 0.

No.

1. Optimizing compilers exist.

2. Addressing at fixed offsets is cheap (a single instruction): https://en.wikipedia.org/wiki/Addressing_mode

0-based indexing is superior (as a default) because it simplifies a lot of common math, as discussed in TFA.

> 0-based indexing is superior (as a default) because it simplifies a lot of common math, as discussed in TFA.

If that was true, Fortran, Julia, R and Matlab would use 0 instead of 1-based.

3. Less buggy for small systems since the Base Pointer address points directly to a record.

4. Macro expansion is often used to store indexes and other 'magic numbers' in Assembler, and this pattern originated either when Assembly was the primary programming language, or even earlier when humans directly punched out cards with machine instructions. Compilers in any remote sense of the luxury we have today did not exist or were not common.

That is true for vectors, but not matrices, right?

  char at(char matrix[10][10], char i, char j) {
    return matrix[i][j];
  }

still has more computation on 1-indexed than on 0-indexed, I believe.

TFA = Thanks For Asking?

I'm fine with 0-based, 1-based or anything-based arrays (I recall it being convenient solving 8queen with pascal), but for Rage-Over-A-Lost-Penny sake, music note intervals are always beyond my understanding.

Same pitched notes are called "interval 1" and there goes thirds, fifths, sevenths... All off-by-one in my base-offset-addressing mind... And then major vs. minor which creates all kinds of "aliased addresses"...

I'd really love a BASE-12 floating number representation. Like 4.00 for the middle C; Chords can be then represented by a tuple of such numbers -- major = [+0.04, +0.07] (some sequencers already do something like that and I'm far better at reading that kind of sequencer data than a sheet)

You do understand that besides thirds, fifths and sevenths, there really are seconds, fourths, sixths, ninths (same as second), elevenths (same as fourth) etc... as well, right? There even are intervals that are not named after a number e.g. the "tritone". The reason the 2nd and the 3rd note in a chord are called third and fifth is because usually chords are made with these intervals instead of dissonant intervals like seconds or fourths. It seems pretty clear you'd already know these things, so can you explain what's your issue with music note intervals?

And then, there's the imperial system.

I found it interesting that the author phrased their critique so definitely, i.e. "it's NOT this and NOT that", yet concluded the article by saying their whole argument was speculative. That said, I do agree with their premise that it's going to be pretty tough to get a definitive answer as to why 0-indexing won out. And their criticism of others being so ready to declare results is apt, if not a little ironic in this case :)

> yet concluded the article by saying their whole argument was speculative

It's possible to have a speculative argument and also refute other arguments that claim certainty. Pointing out another answer as being wrong does not mean one needs to know the correct answer or claim to have a precise answer.

When he talked about BASIC having 1-based arrays, I had to check my memory against online AppleSoft BASIC documentation and indeed, AppleSoft, at least did have 0-based arrays.¹ I also had to check on Pascal which I haven’t written anything significant in for some 20 years and it turns out that by default, Pascal arrays are 1-based, but most of the code that I worked with (which tended to have its roots in Knuth-written Pascal) explicitly specified the range of indices.

⸻

1. As did all the other contemporaneous BASICs that I encountered. For added fun, when creating an array with DIM, you gave the highest index and not the number of elements so, e.g., DIM A(20) created a 21-element array. The 1980 Apple ][ manual I found which discusses both Integer BASIC and AppleSoft doesn’t admit that 0 is a valid index for an array, but elsewhere I saw it indicated as such which leads me to suspect that Integer BASIC has 1-based arrays.

Most of the BASICs I remember had 0-based indexing by default. But you could change this with the statement OPTION BASE 1 at the top of your program.

This was true of even TI-99/4A BASIC, which was closer to Dartmouth BASIC and not written by Microsoft.

Modern Basic (VBA etc.) still supports 1 based arrays, and there's even Option Base (0|1). This is a global directive for all arrays declared in the same file. And individual arrays can be declared with any starting index you like.

I may think that counting 0 as a natural number makes a lot of math more elegant, but clearly I’m just too dumb to rise to the level of wrong.

  fruits = ['apple'] \\ Hello I have fruits 
  x = len(fruits)    \\ Only one kind tho lol
  fruits[x]          \\ OK here is what I have
    SUBSCRIPT OUT OF RANGE

I have always hated zero indexing for this reason (other than thinking in assembler where it is beautiful). It is of course useful in many contexts, albeit with tradeoffs; more importantly everyone is used to it and it's predictable. But I was absolutely thrilled to discover Julia defaults to indexing from 1 like a normal person.

Essentially what we have here is a mismatch between the tool (computer that does everything in binary) and the task (mathematical abstraction of quantities). Now it's completely understandable that people work within the limitations of the tool when there is no other choice, but that's the same sort of path dependency that creates technical debt.

If zero indexing were so great, mathematicians would have made it the default centuries if not millennia ago; but mathematicians don't want to do off-by-1 adjustments on all sorts of common operations because it makes things unnecessarily complicated. To be honest, I think this has become a moat to keep people out of programming even though it's a shallow one.

It could be interesting to test this, say by taking two classes of schoolchildren and teaching one Julia and the other Python (or...). By not having to take on the idea of zero-indexing at the same time as the concept of an array, the Julia group can get into collections using their intuitive understanding of the natural numbers. I expect that picking up language elements quickly will have a compounding effect and that at the end of the evaluation period the Julia group will be able to make significantly more complex programs than a control group.

Edit: in your heart you know I'm right

> If zero indexing were so great, mathematicians would have made it the default centuries if not millennia ago

They did. For any context where the index contributes to the math[1] (i.e. is not simply a label convention like "the x (first) component") the index always start at zero. Polynomials, Fourier series, geometric series, Bessel functions (both their order and their series expansions), etc.

[1]: Except, of course, when a divergent 1/0 term shows up.

Also, considering that Python uses -1 for indexing the last element, instead of -0, which means the last element is not an offset when using negative indices.

Funny, just a few hours ago I asked myself the related question "Should indices start with 0 or 1?" (not for the first time). I pretty much switch my opinion as many times as I think about it.

Here is a nice discussion on stackoverflow https://cseducators.stackexchange.com/questions/5023/why-do-...

The first answer nicely retells the dijkstra argument: integer ranges should be described using half open intervals, and [n, m) is nicer than (n, m]. Furthermore, [0, n) is nicer than [1, n+1), and that's that.

The second answer makes the observation that there is a difference between indexing and counting, and that even in daily life often the first element is indexed by 0.

Still, I rather like indexing the first element of a sequence with 1.

> The usual arguments involving pointer arithmetic

Yeah, I think this exactly why it is zero based. The index became a simple multiplier for sizeof(int).

An assembler spillover into C.

Was C ever much more than a veneer on top of assembler?

Don't get me wrong, it's why I like C.

The crucial fact is that if your language supports 0-indexing, you can do that if you like. OR, you can pretend it has 1-indexing, and do that instead.

If your language doesn't support zero-indexing, then you are stuck with 1-indexing, and that's that.

So, zero-indexing is the natural thing to put in a language, as it accommodates everybody.

"It's an offset from the beginning. The first element is 0 slots from the beginning." is what I was taught. (Of course, it's more complicated than that, with pointer math etc etc, but that works as a general gist)

In the past, I've written roughly half a million lines of Lua. Arrays don't always start at 0. I've regularly shaken my fist at Lua and cursed it's wicked ways, but it's really damn useful in a lot of contexts.

Indexes start at 1. Offsets start at 0.

Arrays in programming use offsets.

    for(int i=0;i<10;i++) 
    {
       array[i] = x;
    }

The error here is calling it 'i' for index. It should be 'o' for offset.

Arrays in the programming languages you’re familiar with use offsets.

Not all do [1].

1. https://therenegadecoder.com/code/which-programming-language...

Because zero is a concept that can mean "at the beginning"

The symbol changed over time as positional notation (for which zero was crucial), made its way to the Babylonian empire and from there to India, via the Greeks (in whose own culture zero made a late and only occasional appearance; the Romans had no trace of it at all)

Another meaning is "nothing" but we're talking about position, not nothingness

The mathematical zero and the philosophical notion of nothingness are related but are not the same. Nothingness plays a central role very early on in Indian thought (there called sunya), and we find speculation in virtually all cosmogonical myths about what must have preceded the world's creation. So in the Bible's book of Genesis (1:2): "And the earth was without form, and void."

https://www.scientificamerican.com/article/what-is-the-origi...

I find 0-based indexing easier to work with when working with (dynamically sized) multi-dimensional arrays. For example, with 0-based indexing getting an element at (x, y, z) can be done with

  a[z * h * w + y * w + x]

But with 1-based indexing you need to substract one first from each component except the last:

  a[(z - 1) * h * w + (y - 1) * w + x]

The 1900's were the twentieth century. Except the year 1900 specifically was still the nineteenth century; the twentieth century started in 1901 and ended at the end of 2000, much to the chagrin of all the chumps who celebrated the millennium a year early.

You know what would make all this confusion go away? Zero-based indexing.

In English, the day of your birth, when you're 0, is also your birthday. So, technically speaking, when you're turning 29, you're having your 30th birthday, even though no-one says it like that. I always assumed 0-based indexing was something like that, similar to the example given about the ground floor being the 0th floor in some countries and the first floor in others.

Another example is if I'm getting directions from someone, and they say, "Walk 3 blocks that way", in my mind I conceptualize that I'm presently on the 0th block and I don't yet count it.

I don't think every day people disagree with these examples so much (well, maybe the birthday one, but that's because we use the same word for the literal day as well as anniversary), and they're all fairly intuitive. I never realized that 0-based indexing required such a deep background to be justified.

> In English, the day of your birth, when you're 0, is also your birthday.

That depends on whether you think of "birthday" as synonymous with "the actual day of my birth" or "a celebration of the day of my birth". I think most of us actual consider it the latter, which is why the first one is after you've been born for a year. If you look up the definition of "birthday" (one word, no spaces) you'll see that there is often some acknowledgement of this in the differing definitions offered.

> "Walk 3 blocks that way", in my mind I conceptualize that I'm presently on the 0th block and I don't yet count it.

You have to decide whether the person is saying something is on the third block from your position, or you need to walk about three blocks of distance. You probably do this automatically based on how close you are to the edge of the current block. If I'm 30 feet from the edge of a black, I'm probably not going to include the current block in that distance. I imagine you probably won't as well.

> they're all fairly intuitive. I never realized that 0-based indexing required such a deep background to be justified.

I think they're only intuitive because we're all context sensitive. The issue is when people don't have the same context, or the context no longer strictly makes sense when the terminology is used in contexts that make less sense.

As an offset, and in programming languages where it's easy to see it's an offset (C), it makes perfect sense. In languages where that's all hidden from you, and you're really just referencing the nth item in a list, the 0th item doesn't make a lot of sense. People in these different contexts will likely have different ideas of what "intuitive" means with regards to this.

I liked how in Pascal, one had a lot more flexibility here.

Something like the following IIRC: Type IntArray = Array [-10...10] of Integer;

what size is that array? (hint - is not 20)

In Mathematica/Wolfram Languege, the part 0 of an expression is reserved for the head of the expression: f[x, y, z][[0]] == f. Or g[f][x, y][[0, 1]] == f.

I started programming in assembly, then Fortran, Algol, COBOL, etc.

0 based index makes sense to me. The memory location is offset 0 bytes from where the first data byte is stored (without getting into endianism).

For me, it was 1 based index that makes sense to me.

I started programming in FORTRAN, then COBOL, then (Lord help me) RPG II. All had 1 based arrays. I got paid to program in RPG II eight hours a day, five days a week, for two and a half years.

A common bit of code was to create an array of month names. Then take an input date, say 20220825, and split that into $Year (first four characters) and $MonthNumber (next two) and $Day (next two).

$MonthIndex = strip the leading zero (if present) from $MonthNumber

Then, this code worked: $MonthName = @Month[$MonthIndex]

When I ran into my first language with 0 based arrays, and @Month[1] returned February, I was pretty much convinced you all had gone insane. December is an out of bounds condition now? Really?

Much later, a friend explained the stuff about multiplying the index by the array element length, and easily getting the memory location of the item in that array. It does make sense; but, I've always hated the code I've had to write that says $MonthName = @Month[$MonthNumber - 1]

Simple answer: because everything in computers starts at 0. Address 0 is the first byte of memory, etc.

You can now ask, "why does everything start with 0"? I guess because it gives you nice round (base-2) numbers. With 4 bits you can have 16 different "numbers", either 0 to 15 or 1 to 16. However, representing the number "16" in binary requires 5 bits, so you need an additional bit for the same number of elements. So representing 4 bits as 0 to 15 makes more sense

The correct starting ordinal is 0. A list with a 0th element has cardinality 1. This is a concept that exists in many places in english, where the naturality of starting with the zeroth element trumps inertia but english is wildly inconsistent so it has both.

Constructing the naturals without including 0 and starting with it is incredibly awkward. Addition doesn't even have an identity.

Look at a clock, is 1 at the top, or is it the next one after the top.

Look at a ruler. Does it start at 1?

Do you want to have to shuffle everything around when you go from whole numbers to halves? Do you start at 0.5 or 0? Depends if it is "halves" or the real number 0.5

This is a recipe for pain and off by ones any time you're dealing with time steps (which is why it's so stupid that matlab and fortran are 1 indexed by default, if anything there's a better argument for C to be 1 indexed than scientific languages).

Now index and compose a bunch of ranges. A half open range of two elements is incredibly stupid 1 <= i < 3.

So closed ranges go with 1 indexing. Composing and splitting them is incredibly awkward [a,c] is split into [a,b], [b+1, c] ... that's kind of okay, but not unique as you could use [a,b-1], [b,c]. Now do [d,e], [e,f] compose at a glance?

Half open ranges go with zero indexing and they just work.

So that modulo works the way god intended inside a ring buffer.

I've spent so long working with both 0-indexed and 1-indexed (I work with Lua a LOT at work) that it makes almost no difference to me, and I can switch between the two with usually no hiccups.

Either one is something you get used to with practice. I do prefer 0-based, but 1-based isn't as big of a deal as many people treat it in the vast majority of situations, and almost every situation where you'd be using something like Lua in the first place.

my thought is just "why not"?

0 is a number, and just because the west ignored it for quite some time (read: "Zero: The Biography of a Dangerous Idea") we have these odd built-in aversions to it but in the end it makes plenty of sense.

0th element is 0, so why don't we just do a better job of educating kids to start counting with 0 and thinking about 0.

in the end - as a CS person, i think it's good - but i also don't mind if you disagree with me. :)

If it starts at zero we should call it an "offset"

That would fix so many of these discussions.

Maybe, but then they'd just become discussions about whether `y` in the `x[y]` syntax "should" be an offset or an index. Which one gets the language priority?

...Of course, the answer is offset, because offsets are beautiful, composable, elegant things that harmonize with bitmasks, modulo, array slices, and everything else, while (one-based) indexes are nothing but "offset plus one", no more useful than "offset plus two".

0-based indexing is clearly the best option because it results in more elegant code and it matches what computers actually do.

In fact, it's so fundamentally more elegant that I've come to the conclusion that the real issue is that it's actually the mathematicians and language itself that got indexing wrong. Instead of "first" being associated with 1, it should be associated with 0. We should give athletes 0th place, and talk about the 0th man on the moon etc.

That's where the cognitive dissonance for the 1-based-indexing people is coming from. They can't deal with the fact that their "normal" way of indexing is wrong.

It's a bit like how pi should really be tau (2*pi), or the electron should really be positive. We got it wrong, but we're stuck with it because it's too much of a hassle to change it. Fortunately computing got it right! But now there's a mismatch with everyday life where people are used to the wrong thing.

Ignoring the past; 0 indexing is:

- closer to hardware

- makes index == element wise offset from the first element

- there are both algorithm which are (very slightly) easier to implement with 0 and 1 indexing, AFIK more of the "bread and butter" algorithm are easier with 0 then 1 (e.g. indexing of C-style arrays used all the time, heaps etc.)

- 0 is not special => less bounds checks in typed languages (if you have an unsigned int index you only have to check the upper bounds, with 1-index you also have to check for 0)

- 0 is not special => with signed integer you can have negative indices (from the end) in which case all signed integers are valid (but potential out of bounds), with 1 indexing you have a "gap" in the middle which for some (rare) use cases can be very painful to handle

So independent of what the history was. It's just much more pragmatic to use 0-indexing in many common use-cases. Especially given that 1-indexing produces more special cases for very common use-cases makes it sub-optimal for both usability and performance.

Reminds me of a simple implementation of a Prisoners and Boxes riddle that showed up in my YouTube feed where I had to add a comment so others (and eventually future older me) will understand what I did.

>// if one prisoner fails all are dead (1st try -> tries = 0)

https://gist.github.com/amalic/c107b5289d946b758418778a95fdc...

That being said, it seems to be a junior software engineer issue where the brain isn't wired yet for "0-based" indexing. I don't hear such complaints from more experienced developers who have simply learned to appreciate it because like in my example above it is more intuitive to me.

I have added "and eventually future older me" above because I don't do much coding these days, and my career trajectory looks like it's going to be even less in the future.

I can understand the rationale for 0 and 1. I can even understand the rationale for a arbitrary range (from -5 to +10) in current era where languages have iterated for many generations.

However I did not understand why they would have a range in the early days of programming. On one hand it would have been hard to make a language and its compilers and then you add arbitrary ranges?

Early programmers were mostly mathematicians and physicists, so the notation borrowed a lot from their fields, where it's common to index sequences with arbitrary numbers. And it's not particularly complicated to implement either.

I always assumed it came back to math, and that t0 or time-zero is useful for the beginning state before anything happens.

What if there was no t0 for the universe, as Hawking and a few other physicists have argued? There was just the first plank second and no meaningful before.

Another reason can be performance/memory.

When you index starting at 1, you either have to add/subtract 1 internally, which sometimes but not always can be optimized away by a smart JIT/compiler, or you have to "waste" the first element in memory, trading memory for performance.

Lua always subtracts 1, while LuaJIT instead went with the latter approach.

For me, far more significant than anything else here is having to convert array indices into human readable text describing objects. And the objects are named by mechanical engineers who don't use 0 based indexing. So my code is full of

  print("Finger {}'s motor has overheated".format(i+1))

I think that zero indexed is generally better, including that it involves adding the index number to the base address, and other properties that can be helpful.

However, it can also be useful for many purposes to allow arbitrary ranges, so a programming language probably should allow that; if the index of the first element is not zero, then the base address will not be the address of the first element (if the first element index is positive, then the base address may actually point into a different array, or a different variable). Then, if you have the base address and add the index, you will have the proper address of that element, whether or not the first index number is zero.

Zero is not always the most useful starting index; sometimes other numbers (which may be positive or negative) are useful. But, I think in general, zero is better.

The best source for the development of C language is Bell Labs https://www.bell-labs.com/usr/dmr/www/chist.html

Excerpt:

   By a general rule, in B the expression
      *(V+i)
   adds V and i, and refers to the i-th location after V.
   Both BCPL and B each add special notation to sweeten such 
   array accesses; in B an equivalent expression is V[i]

C was designed to be as close to the machine as possible. Prior to C the only programming language for systems programming was assembly. If the compiler-generated code subtracted 1 from the index every time you indexed an array that would have been seen as not as efficient as assembly.

Maybe my thinking is just warped by the language, but I think 0 indexing is the right thing most-- but not all-- of the time. Looking at my code I have relatively few places where I need to -1 to convert a natural 1 index into a zero index.

It would be easy for languages to offer two array access syntaxes, one for 0 and one for 1 like array[i] for 0 index and array{i} for 1 index access, then the accessing code could use the right tool for the job. Unlike defining the indexing type as a property of an array you shouldn't have problems with accidentally using the wrong one at time of use.

... but to really know if it's a good idea you'd have to test it, and sadly very few concepts in programming are subjected to any kind of rigorous scientific study.

Starting at one led to the whole "2000 is not the millennium" thing, as there is no year zero.

Even more painful is that the 2001 began the 21st century, not the 20th.

Array indices denote offsets from the base address. The first element is at the base address of the array, hence the offset is zero. It avoids a conditional when resolving the address, introducing it would slow down all forms of memory access across the language domain.

Yet somehow Fortran manages to be highly performant.

After programming in C for a while, I really began to have the feeling that arrays were physical things that took up space in RAM. When I think like this, starting an index at 0 is very intuitive, as 0 implies the origin point of the physical construct.

If you think of arrays just as a kind of abstract list, then beginning at 1 makes much more sense. No one who looks at a to-do list at home talks about the 0th thing on their list to do. But the spacial nature of arrays makes starting at 1 confusing. After I take 1 step, I am no longer at my starting point. And cycling through arrays in code for me has a very similar feeling to taking actual physical steps through a data structure.

An Array in Ada is interesting. https://learn.adacore.com/courses/intro-to-ada/chapters/arra...

Like other languages, it is a collection of contiguous elements that can be selected by indexing.

Unlike other languages:

- any discrete type can be used for indexing, not just integers

- bounds can be any value (doesn’t have to start at 0 or 1. First index could be 13)

- one consequence of the aforementioned is that arrays are types that map to the problem domain, rather than being tied to the computing domain

- and more…

I'd claim intuitively that having all bits 0 is a proper starting point and more efficient if there were any constraints on address, which was likely the case historically.

I'm happy to hear any dissenting opinions if this is inaccurate.

"math [...] sums seem to always be 0-indexed,"

What? Is this some kind of trolling challenge? If you don't care about math, just say so. Most people don't. But making up a nonexistent convention is just silly.

If your arrays start at 0, you have offsets.

If your arrays start at 1, you have indexes.

"0-indexed" shouldn't be a thing. I like the screenshot quote that refers to this as either "1-origin" or "0-origin".

A related question: why is a rectangle containing a single pixel defined as (x,y):(x+1,y+1) instead of (x,y):(x,y)?

Here's a discussion from some years ago that starts with some of Guido's thoughts on array indexing and moves on to the QuickDraw coordinate plane and points and rectangles, including how grid lines and points are infinitely thin/small, but pixels occupy the space between the grid lines.

https://news.ycombinator.com/item?id=6602497

The general term of arithmetic and geometric sequences seem simpler when indexing from 0 rather than 1. I do not think that '1' is more human focused for anything than '0'.

Its an absolute pain in my arse, i honestly don't know what problems i would have with an array system that started at 1, but since the length method sometimes starts at 0 and sometimes 1, (I'm thinking Perl vs JS) I'm always forgetting whether to put = or <= into for loops and when to add one for the read out or subtract 1 when looking at the array again. I mean in what universe should [2]+[3]=7?

The first element having the index zero may be natural or unnatural depending on the context. In mathematics, we count the rows in a matrix starting from 1, but we count the monomials in a polynomial starting (or ending) with 0. Generally, there is less need to use zero as the starting index: the Common Era does not have "the year zero" (there, -1 is followed by +1), etc.

Easy: I have an array with 256 elements. And I want to store the indexes of various elements of the array off in another data structure. So many of them, in fact, that it’s important that the index values each fit into a byte. So, I want the index values to be 0..255, and not 1..256, since 256 doesn’t fit into a byte.

You can still fit that information into one byte and convert it at compile time or runtime :)

In a minecraft clone I made, each chunk consists of 16 subchunks so that I only need 12 bits to represent the block position in the shader. Technically, the block position ranges from INT32_MIN -> INT32_MAX, but since each subchunk only consists of 16x16x16 blocks I can get away with storing the position in 12 bits and then passing in the subchunk's world position once as a uniform.

That reminds me of this article about the history of hjkl in VIM: https://www.hillelwayne.com/post/always-more-history/

Lo and behold, it's written by the same author.

Arrays start at 0 because they're really just pointers. "[x]" is just shorthand for "+ x * sizeof". The first element is the one stored at the pointer address (0 sizeofs ahead of the pointer, the next element is stored 1 sizeof ahead of the pointer, etc.

In C, "a[x]" is effectively syntactic sugar for just "*(a+x)" (conversion rules for "+" means you don't need the sizeof). It also means you can reverse it and write e.g. "5[somearray]" if you really want to make developers want to throw rocks at you.

That's just convention though. There's no reason "[x]" couldn't have been defined to be "+ (x - 1) * sizeof". There would be no runtime cost to this, and the compile time penalty would be tiny even on ancient systems.

That answers something like "what are the technical benefits to zero-based arrays" but not "why are zero-based arrays such a strong convention in programming languages." For that you'd have to read the article I guess.

The article this one points to has had a few threads:

The origin of zero-based array indexing - https://news.ycombinator.com/item?id=6879478 - Dec 2013 (107 comments)

Zero-based arrays and the mythology of programming - https://news.ycombinator.com/item?id=6708409 - Nov 2013 (1 comment)

Citation Needed - https://news.ycombinator.com/item?id=6595521 - Oct 2013 (2 comments)

Threads about the EWD mentioned by jaapsen01:

Why numbering should start at zero (1982) - https://news.ycombinator.com/item?id=22162705 - Jan 2020 (220 comments)

Dijkstra's argument on why numbering should start at zero [pdf] - https://news.ycombinator.com/item?id=17850441 - Aug 2018 (1 comment)

Why numbering should start at zero (1982) - https://news.ycombinator.com/item?id=17765034 - Aug 2018 (63 comments)

Why numbering should start at zero (1982) - https://news.ycombinator.com/item?id=13186225 - Dec 2016 (216 comments)

Why numbering should start at zero (1982) - https://news.ycombinator.com/item?id=9761355 - June 2015 (47 comments)

Dijkstra: Why numbering should start at zero - https://news.ycombinator.com/item?id=777580 - Aug 2009 (71 comments)

Also these. Others? I'm a little surprised there aren't more.

Why do we count starting from zero? - https://news.ycombinator.com/item?id=17923391 - Sept 2018 (1 comment)

Why C Arrays Start at Zero: I Don't Know - https://news.ycombinator.com/item?id=11228267 - March 2016 (3 comments)

Why C Arrays Start at Zero: I Don't Know - https://news.ycombinator.com/item?id=11114704 - Feb 2016 (2 comments)

Perhaps also worth adding that the linked article (the one titled "Citation Needed") itself originally had hundreds of comments beneath it, many quite argumentative, which seem to be now missing - I guess lost in a site update. It was a very contentious article.

I'm sympathetic to its author's approach - we talk about indexing and it's a strangely fascinating topic but the history of it hasn't been all that well dug out. We do indeed tend to respond to articles like this by going "well obviously [x]-based is good because" - you can see that at work in this discussion here - but those are not necessarily the true historical reasons. But I think the author made a leap too far, the article was a bit too brittle, and it landed in a slightly too argumentative spot.

Because indexing happens with integers. Back then space was a concern, so you'd use unsigned integers, and those start with zero. Internally they'll all be using offsets, and its easier to not do a conversion, than to do a conversion.

Unfortunate that the Julia folks weren't exposed to this when they designed the language.

https://juliaarrays.github.io/OffsetArrays.jl/stable/

0-based or any arbitrary offset of your choice so that your data model can more closely map to what you need it to. And use eachindex instead of making assumptions and you can work with arrays using 1-based, 0-based, or arbitrary-based indexing.

Looking at my own coding experience, I certainly favor 0 over 1. When I examine why, I can't help but see my aversion to & distaste of Visual Basic as a driver.

VB is the only 1-indexed language I have used. VB is bad. Therefore 1-indexed languages must be bad.

The index of an array is an integer, and integer values start at zero, so it seems like an obvious choice as to where the starting point should be. It's only outside of computer science that it seems to be counter-intuitive.

There is definitely a bunch of math that works out better in 0 based indices. I saw this a lot when I was working on filesystem focused stuff.

I feel like I've also seen algorithms that work out better with 1 based indices, but not as many.

https://blog.nelhage.com/2015/08/indices-point-between-eleme...

Actually in not all languages do arrays start at 0. In ColdFusion for example arrays start at 1. I've never been able to receive a reason as to why CF's original author, J.J. Allaire, did it that way.

Came here to say this about CF. I work in Coldfusion but coming from a background of other languages I would always reference 0 as the start of an array. This was the source of countless errors for me until I got use to it.

My manager thinks it was done to make the language easier to understand for people just getting into programming.

And Julia, an otherwise nice language.

also Lua and R.

Almost as interesting as hearing arguments for/against tabs/spaces.

The argument that "BCPL doesn't have pointers, so it's not about pointers" fails immediately because every language has pointers, but some of them don't expose them to the developer.

Nobody mentioned Lua? Really?

Lua's arrays are 1-indexed, and it is a terrific interpreted language! Array[0] is nil, makes sense. v5.1 has a solid JIT, and it's got a great 2D game engine called Löve2D.

Pascal and SQL also use 1-based arrays

Because back when computers were young, all bit representations were needed to represent something and having 000 not be used as a valid value wastes a huge percentage of available space.

In defense of starting at 1: if you're counting things, starting at 1 ensures that the last number you said is equal to the number of things you've counted so far.

Toddlers love this invariant.

I always assumed that it was because arrays and pointers would've been interchangeable in the start, and that adding a zero index times the object size gives you the first element

Because memory starts at zero, because the lowest address you can select in memory has all its address lines set to zero.

If you don't understand this, you should not be writing computer software.

Welcome to pagination and virtualization where physical address is different than what your program think is. Also welcome to hypervisors where entire operating systems think they own an entire physical line, only to have something like Spectre/Meltdown say otherwise.

Because sometimes we number things, and sometimes we count things.

base^0 = 1 base^1 = base base^2 = base * base et cetera.

I've always considered the index and the power to which a base has been raised to be equivalent in many circumstances.

Thus starting at 0 makes sense.

Discussion form 2013: https://news.ycombinator.com/item?id=6601515

Wow, we are still talking about this, are we? Honestly, linear algebra texts should just give in and adopt zero based indexing for matrices at this point.

The concept of nothing doesn’t really belong in the number line. It’s like inventing a new “number” to represent blue and then using it instead of pi.

Simple: Because you add zero to the memory address of an array to access the first element.

The array indexer was syntactic sugar for pointer arithmetic.

Qbasic uses 1 and that’s what I always loved about it. Coincidentally it was the same language I learned programming with at age 12.

I always thought it was because it’s easier multiplying the index by the size of the array item to get the correct offset

I write code that interfaces between C# and R and you have to be careful to remember to do the indexing change. Fun!

Languages like fortran and Ada allow arrays to start at any index. This allows you to do what matches your problem.

Natural numbers start at 0, so it makes sense.

1 is just as arbitrary as 2 or 79823 etc. Math wouldn't work without 0.

Thats good enough for me.

So what's the actual reason you'd want to have zero based arrays and such in your language (In 2020, not 1970)? In a language from scratch that doesn't care about being like previous ones, and doesn't care about micro optimization.

I've been annoyed recently by this obnoxious neckbeard behavior when they make things zero based for no reason (other than to conform to their supposedly existent philosophy), like Ratpoison and Screen selecting windows by a zero based index, which means you have to move your hand to the far right of the keyboard to select the first window with the 0 key, the far left to select the second window, with the 1 key, and one to the right to select the third window, with the 2 key.

I so happen to have been trying to work out a tangible explanation on paper of which system is better on trips a few weeks ago, and could not come up with one (and none are given in the article nor the top comments in this thread).

On a side note, the moment you say, "zeroeth", you can no longer be sure anyone knows what you're talking about because at any moment you may count in English or this pretentious UN*Xtard dialect of English. Seems like another pedagogical stumbling block held on to boomers and boomer-wannabes who just want to have their little counter counter counter culture or whatever.

My 4 year old starts at 0 when asked to count, so proud! Never said a thing about starting at 0.

They point at 3 apples and goes "0,1,2" naturally?

Look at your 4 year old's ruler. What's the first number on it?

A problem with 0-based arrays is that 0 is the only index with a Falsely Boolean value.

Because ordinal counting has been a tenant of computer science since inception.

Because an array is just syntactic sugar for pointer arithmetic ... at least in C :)

If everyone just called it offset instead of index there'd be no confusion.

For me it comes down to; are you enumerating intervals or items to offset into.

Seeing 544 comments about this story has restored my faith in HN. :-)

It's an offset from the beginning. Simple as that.

Simple: because we start with index 0 in mathematics.

I have encountered a lot of linear algebra textbooks that use 1-indexing to describe matrices and matrix operations.

Pascal's arrays start at 1, at least by default.

This is false. Pascal arrays start at whatever you want. As for what is happening behind closed doors (aka linker), those start at zero, but with an offset kept separately (that's why C blew out of the water Pascal in terms of speed when looping through an array). And in Pascal you cannot create a dynamic array with anything other than 0-based.

You are confusing arrays with strings. Those used to start at 1, but since Unicode took over (~2007) strings are implemented as zero-based too (even though you can still think of them as 1-based when writing code).

Also in Delphi, when creating a cross-platform application, strings are treated as 0-based, with even multiple locations in documentation stressing this importance due to having enough differences between classic VCL and the new kid on the block (aka FireMonkey).

Pretty much all variants of BASIC have arrays starting at 1.

BSD bash arrays are 1 indexed for some reason

But the first year of this century was 2001…

Good article.

Especially the DBAD comment.

Why do months start at 0? is my real claim.

The Lessons section is brilliant.

0 is offset based. 1 is index based.

This is my take and when working directly with computer memory/addresses, 0-based is most convenient. For working with data/stuff at a higher level, 1-based is more natural and convenient.

Why do tape measures start at 0?

Obligatory, there are a lot of memes on this subject:

https://www.google.com/search?q=arrays+start+at+zero+meme&tb...

data Position = Start | Next Position

Zero-based indexing is always wrong; an ordered collection of things does not have a zeroth thing.

Sometimes you have a data structure called an "array", which means "a bunch of things that are the same size next to each other in memory". You can store the address of the whole array as the address of its first element, and offset into it by an offset; clearly, the offset of the first element is zero, but it's not the "zeroth" element.

And finally, sometimes you have cargo cult behavior by people who think that the way offsets into arrays work is because "numbering starts at zero in computers!" or some similarly wrong rationalization. This is when you get stupid things like (nth 0 list) in a lisp.

I hate to break it to you but natural spoken language is not a fixed concept, words can have many meanings and interpretations, and those meanings and interpretations can mean different things to different people at different times.

Because you predominantly think of indexing as the first definition as shown here[1], does not mean everyone else does. Be careful when using absolutes, especially when talking about languages.

[1] - https://www.merriam-webster.com/dictionary/index

An ordered collection of things starts no things from the beginning.

A journey starts 0 metres from the origin.

If you count the number of _ you are along your journey and start with 1, then at the second metre you are at the 101st centimetre.

When someone says how many dragons have you slain? Just as you leave and haven't heard of any dragons yet, you don't say "I'm slaying my first dragon now"

Every construction of the natural numbers I have seen starts with 0.

The first hour of the day has passed when the clock strikes one. The hour preceding that is the same day. English calls it 12 because it was invented before we had a firm grasp of zero and english is inconsistent. 24 hour clocks call it 00.

1 based indexing can be correct, but 1 based ordered discrete sets map incredibly poorly to any ordered set with a different number of elements (such as the reals). Additionally dealing with ranges is less easy to make consistent.

0 based indexing is always correct.

An ordered collection of events in time usually starts at t(0).

Some guitars have a zeroth fret; an actual fret at the nut.

This reminds me of arguments about male -> female and man -> woman (and human etc). Without offending anyone's delicate sensibilities - you may note that there is a short version and long version of those words, suggesting that the longer version is derivative of the short version.

However, when you examine the origin of the words, that is not the derivation. The derivation and path to English is quite complicated. You may feel a sense of righteous indignation or righteous repudiation on this topic. I would gently suggest deferring that feeling because I think the story is very interesting to follow.

That is not the end of the story though. The reason those pairs of words stuck around is almost certainly because it makes a consistent mental picture.

Bringing it back to the topic at hand - "Why we use 0" - because it works. There are many times when it has been evaluated, and at least to the people who design languages, it is more mentally appealing.

https://www.etymologynerd.com/blog/man-vs-woman

https://medium.com/interesting-histories/interesting-histori...

I really fail to understand what the etymology of sex and gender classifications has to do with array based indexing.

Reply on news.ycombinator.com