Live data from Hacker News

Why do arrays start at 0?

buttondown.email

311–320 of 702 posts

Re: Why do arrays start at 0?

#311

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 0: 00 1: 01 2: 10 3: 11 To write 4 numbers if you avoid using the number zero, you need three bits 1: 001 2: 010 3: 011 4: 100 If you extrapolate that a little bit, you'll realize that you'll need two bytes (1 Byte + 1 bit…

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 8…

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.

Re: Why do arrays start at 0?

#312
post #235

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 addres…

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.

Re: Why do arrays start at 0?

#313
post #235

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 addres…

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.

“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.

Re: Why do arrays start at 0?

#314
post #235

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 addres…

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.

Re: Why do arrays start at 0?

#315
post #257

Earlier quoted context omitted.

No, old calendar systems are one indexed. In those system, there is literally no year zero; the first year is year one. This leads to crazy things like year 100 being part of the "first century" and year 101 being part of the "second century". That is not the case with age or birthdays which are, thankfully, zero indexed. The first year of human life is age=0, birthdays=0.

It's not "crazy". No one care about which century X00 is. The term "century" doesn't have enough sig figs. X00 is "the turn of the century".

If you don't care then sure, it's not crazy, but if you did care then believe me, it is crazy. Crazy enough that astronomers[0] and software engineers[1] rebelled against the historian's practice and renamed the years preceding 1 AD in the proleptic gregorian calendar year 0, year -1, year -2, et cetera. A major benefit of this is it allows the leap year pattern to stay consistent and the rule to remain legibile for all years, going back before 1 AD. It's also nice because it lets us say "the 90's were the last ten years of the 20th century" and be correct.

0. https://en.wikipedia.org/wiki/Astronomical_year_numbering

1. https://docs.oracle.com/javase/8/docs/api/java/time/temporal...

Re: Why do arrays start at 0?

#316
post #259
post #97

Earlier quoted context omitted.

Ask 100 random people on the street and I'd be surprised if even 1 knew the definition of "ordinal". It's an uncommon word.

So is "array". What's your point? My point is that it is unambiguous once you say what you are talking about.

I disagree. The CS definition of array, sure, but if you were to say “we have an array of options to eat”, most people with a high school education would know what you mean.

Re: Why do arrays start at 0?

#317
post #40

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 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).

Re: Why do arrays start at 0?

#318

Earlier quoted context omitted.

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.

For constant addressing; for arr[i] = 2, you'll still need to subtract 1 from i with 1-based addressing when converting to machine instructions.

Re: Why do arrays start at 0?

#320
post #280

Earlier quoted context omitted.

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.

https://linux.die.net/man/3/localtime : tm_mday: The day of the month, in the range 1 to 31. tm_mon: The number of months since January, in the range 0 to 11. I wonder where C got it? It goes back to at least 1973's V4: https://github.com/dspinellis/unix-history-repo/commit/92779...

https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/...

Convenience. Look at how the days in the months are stored and accessed. Using 1-based months would introduce an extra calculation (-1) on all searches or an unused value in the 0-index. Also look at how printing is handled for weekday and month names. They, again, take advantage of 0-based indexing.

Day and year are already represented as numbers, so it's natural to keep them as the "correct" (conventional) number as used by most people. Since the months aren't being stored as strings but as an index, this saves them from having useless data (entries in 0) or doing an extra calculation.

Post reply on HN