Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why do arrays start at 0?

buttondown.email

Post reply on HN
Print view View original

421–430 of 702 posts

Re: Why do arrays start at 0?

#421

Post by OscarCunningham »

Aardwolf wrote: post #210
hougaard wrote: post #14

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

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

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

That's funny, but there's actually an elegant way to do it called Bijective numeration (https://en.wikipedia.org/wiki/Bijective_numeration). We're currently living in the 1A22th year.

Re: Why do arrays start at 0?

#422

Post by jbaczuk »

diego_sandoval wrote: post #273

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…

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

Re: Why do arrays start at 0?

#423

Post by ivanhoe »

just_boost_it wrote: post #324
blueflow wrote: post #269

Earlier quoted context omitted.

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

20 years ago ASM was just as cryptical black magic to most of programers as it is today... try perhaps 40 y/a...

Re: Why do arrays start at 0?

#424

Post by goatlover »

weavejester wrote: post #202
goatlover wrote: post #167

Earlier quoted context omitted.

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.

Why, it would be an inclusive instead of exclusive range. N is the last element, so no reason for N+1.

Re: Why do arrays start at 0?

#426

Post by adrianmonk »

ajuc wrote: post #404
adrianmonk wrote: post #381

Earlier quoted context omitted.

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

Sum types don't automatically define ordering between the possible values AFAIK? So in your implementation you'd have to manually define the up: (regular | lobby | parking) -> (regular | lobby | parking) down: (regular | lobby | parking) -> (regular | lobby | parking) and which_way: (regular | lobby | parking) x (regular | lobby | parking) -> direction If you use subset of integers you can just use operators inc, dec…

If I build a building in the shape of a double helix, what order are the two floors in?

Hmm, are there actually an infinite number of floors? Do we need to switch to floating point?

Re: Why do arrays start at 0?

#428

Post by btilly »

wizofaus wrote: post #387
btilly wrote: post #353

Earlier quoted context omitted.

Because changing the base is a great source of bugs. That said, not all languages have given up on this. For example Julia allows it. https://docs.julialang.org/en/v1/devdocs/offset-arrays/ Ironically I learned this from a discussion of Julia bugs. Apparently changing offsetting of arrays has proven to be a source of bugs in Julia. So maybe someday they will come to the same conclusion as languages like Perl and stop…

I'd argue 0-base is a source of bugs too! Ideally we'd be able to catch more array indexing bugs at compile time - there are definitely cases where it should be possible to determine that arrays are being incorrectly indexed via static analysis.

The problem is that libraries which assume 0-base break when you have a 1-based array. And vice versa. Trying to combine libraries with different conventions becomes impossible.

Therefore changing the base leads to more bugs than either base alone.

That said, the more you can just use a foreach to not worry about the index at all, the better.

Of 0-based and 1-based, the only data point I have is a side comment of Dijkstra's that the language Mesa allowed both, and found that 0-based arrays lead to the fewest bugs in practice. I'd love better data on that, but this is a good reason to prefer 0-based.

That said, I can work with either. But Python uses 0-based and plpgsql uses 1-based. Switching back and forth gets..annoying.

Re: Why do arrays start at 0?

#429

Post by Schroedingersat »

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

Re: Why do arrays start at 0?

#430

Post by goatlover »

Yujf wrote: post #232
bee_rider wrote: post #9

Earlier quoted context omitted.

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…

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

If you’re calculating indexes at runtime, you’re probably not worried about that level of optimization.
Post reply on HN