Hacker News Reader

Comment by tromp | Hacker News Reader

> We usually start to count from one. When a baby completes its first roundtrip around the Sun, they’re one year old, not zero years old.

And before they complete the first trip, they're 0 years old, showing that you start from a count of 0. The one is the result from the first increment.

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.

For arrays, the first element is the difference between a size 0 array and a size 1 array. So the choice between 0-indexed and 1-indexed is like the difference between pre-increment and post-increment. Do we associate the element with the array size up to the element, or to the array size up to and including the element? The choice seems arbitrary (personally I prefer using the same range of non-negative numbers for both, but language has a bias for associating "first" with index 1).

View on HN

Nobody says that a baby is 0 years old. They use other words instead of numbers, or if they do use a number, it is X hours / days / weeks / months old.

0 in normal usage is always a negation of something existing. You don't start counting things that exist at 0 (as you pointed out in your example of number of red balls in a bag that have none). However, position zero at an array in zero-indexed languages is the first position within the array.

There's no getting around the fact that higher level languages inherited 0 by counting byte offsets, rather than positions, even if those languages don't required that every index within an array have the same size in memory (or occupy a contiguous block of memory), and that this inherited usage is at odds with the actual plain-language and true meaning.

Of course they don't. They use decimals and say the baby is one week old or so.

As for indexing from zero, it's best understood as indexing the position just before elements in an array. Where things will be inserted if you insert an element etc...

So, to use some pseudocode:

var item = my_array[2]

should be read as

"assign to item the value in my_array in the position where you would place something new just before the third item"

1-indexing is, strictly speaking, a better design. The only real argument for it anymore in a higher level language is "it's what I'm used to", or alternatively, "0 already won the popularity contest" (which is actually not a terrible argument in context, though it is a bad one from a purely objective design perspective).

Saying it's strictly better is exaggerated. The benefits of 0 indexing are well known and mostly revolve around the fact you tend to have far less fiddling with -1 and +1 as you write code.

How do you access the item in a 2D array represented on a flat array? my_array[x+ywidth]

But what is all that starts at 1? my_array[x+(y-1)width]

I did a lot of code in both systems and I remember distinctly that 1.. indexing just was more work to do, in turn bringing in more off by 1 bugs.

>The benefits of 0 indexing are well known and mostly revolve around the fact you tend to have far less fiddling with -1 and +1 as you write code.

Depends on what you are doing. I seldom have to do a flat 2D array these days, but array[total-1] is an almost everyday thing.

Dijkstra's arguments [1] about the benefits of 0-indexing are about tricky edge cases when coding with arrays. (The example you give is not a correctness problem, but a memory-efficiency issue: if width=1, you'll not be using at least half of the structure's indices that you allocated). But Lua doesn't have arrays as a type, it only has a way of iterating over the array part of tables, its map data structure.

Idiomatic Lua code for tables doesn't run into the kind of edge cases Dijkstra presents, since the most readable code uses iterators to yield the values of array indices when one wants to access the array part of tables.

It makes perfect sense to add arrays as a userdata type. For these, there are benefits of 0-indexing, as seen in https://github.com/neomantra/lds - although mixing 0-indexed

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

1/52 of a year

3/12 of a year

even after a year, they might say 18/12 of a year.

You start your argument with a missconception, 0 does not relates to the existance of something but rather the lack of. When a bank acount reaches 0 it does not mean money does not exist, neither it means the account does not exist, it just means there are no units there of that you are counting...

> Nobody says that a baby is 0 years old.

Totally irrelevant to the the actual conversation but I have in fact put my infant child’s age as 0 because I didn’t think to count in smaller increments than years. So there is at least one person who says babies are 0 years old.

> Nobody says that a baby is 0 years old

That's only because age can easily be measured and described in units smaller than whole years, while array indexes can't be divided.

While I agree about the points you made, you cant take the zeroth element out of your shopping bag, you take the first one. The array indexing operator gives you access to the nth element of your data store. IMO OPs point is valid.

The point is valid, but the rationale is not, let me explain:

Caring about 0 based or 1 based indexing is, to me, a sign of someone who struggles with programming in general, or is stuck doing a lot of finicky conversion between the two.

Most modern, higher level languages have generally abandoned using indexing, instead (even c++) they have something like:

"for x in y do z"

1-based indexing is a bit more readable, but in the end, you have hardly any benefit. There are better paradigms, algorithms, which don't require indexing at all, which IMO is the majority of what programmers are doing anyways. Even if you need to process two same-size collections at once (the majority of the remaining legitimate uses for index based looping), you are likely working pre-sorted data and should consider using a zip or pair which eliminates the need for managing indexes.

You say "but aren't you just imposing your own style on others"? Not really, if we want clean, minimal code, there should be as few references to the underlying architecture as possible, even the fact that we are dealing with a list is an implementation detail (is it actually a list, a linked list, a stream, a dictionary, an event, etc...), so in the context of implementing a higher-level language, this point is not only irrelevant, but shortsighted. If you are creating and looping over lists, you are likely not doing anything interesting, which is the whole point of programming in higher level languages, to do interesting things simply, right?

As for the remaining use case when we do actually want array based access, typically you find this in high-performance, architecture aware applications - then we actually want random memory access. We may even want to deal with explicit memory offset, which is what 0-based arrays are good at doing (often times the array is syntax sugar and we are literally assigning to/from pointer offsets).

To bring this around to my previous statement: "Caring about 0 based or 1 based indexing is, to me, a sign of someone who struggles with programming in general, or is stuck doing a lot of finicky conversion between the two."

The reason this comes up in the first place is that there is a divide. 0-based arrays are arguably much better for low level activities, and higher level languages generally left them in as a familiarity. Translating from 1 to 0 based arrays is not any easier than translating from 0 based to 1 based arrays, 1-based arrays provide just as much confusion and less familiarity in these cases. This is not a good thing.

Now I suppose Lua is trying to be something weird, a "high level" low-level language. Maybe that's fine, but it is weird, and people are right to be put-off by the change. If you are looping over bananas in lua, maybe you're not really using it the way it was intended, if you are doing memory-level access then its unnecessary language cruft.

You created an unfair definition of the array indexing operator. I can just as easily say that the array indexing operator gives you access to the element at index I, which starts counting at 0. That's not an argument.

The sequence of the cardinal numbers, i.e. of the equivalence classes of sets having the same number of elements, is 0, 1, 2, 3 and so on and those words in any language have been used originally for cardinal numbers, not for ordinal numbers.

For the sequence of the ordinal numbers, whose purpose is to identify the position of the elements of an arbitrary sequence, any sequence of arbitrary symbols may be chosen and fixed by convention.

Most languages had at least in the beginning special words for the first and for the second elements of a sequence, without any relationship with the cardinal numbers. Even in English that remains true, even if "second" is a more recent substitution of the older word used previously. Many languages have special words for the last element and for the element before it. Some languages had special words for the third element and for the third element going backwards from the last. So in some languages it was possible to identify the elements of a 6-element sequence without using words derived from the cardinal numbers.

However inventing a very long sequence of words to be used as ordinal numbers, in order to identify positions in sequences with more than 2 to 6 elements, would have been difficult, so in most languages someone noticed that there already is a sequence of words that everybody had to memorize when learning how to count and which had rules for being extended to any length. So the ordinal numbers were derived by using a suffix or some other derivation rule from the cardinal numbers.

There is no logical reason for using 1 for the first ordinal position, this is just a historical accident.

The reason is that the children have always been taught to count by saying 1, 2, 3 and so on, instead of being taught to recite the sequence of the cardinal numbers from zero.

All the languages have always had a word for zero, but those words were normally created by applying a negation to words meaning "something", "one" or the like.

Because of this, the words for zero were not perceived as having an independent meaning and there was no need to learn them separately when the recitation of the cardinal numbers was learnt.

Nowadays we have a much better understanding of the meaning of the cardinal numbers and we are aware that 0 is a cardinal number like any other, so the children should really be taught to count 0, 1, 2, 3 ... and not 1, 2, 3, ... like 5000 years ago.

In the natural languages there is a huge inertia. Even if one would decide that since tomorrow the ordinal numbers should be 0th, 1th, 2th, 3th, 4th and so on, everybody would still have to know that whenever reading older writings the sequence of the ordinal numbers was 1st, 2nd, 3rd, 4th and so on, so a change of the convention to a more logical one would bring no simplification.

On the other hand, in the programming languages you can ignore the legacy conventions and choose the best conventions. Using for ordinal numbers the sequence 0, 1, 2, 3 ... is the best choice for many reasons, which have been explained in the literature many times, e.g. by Dijkstra.

Choosing to start the ordinal numbers from 1 in a programming language just demonstrates a lack of understanding of what the cardinal numbers and the ordinal numbers are and a lack of practical experience in programming and of understanding of how the programming language will be translated into machine language.

The first programming language for which I have studied the machine code generated by its compiler, when I was young, happened to be Fortran, which uses indices starting from 1. Until today I remember how I considered ugly and error prone all the tricks that the compiler was forced to use in order to avoid in many cases to make extra computations due to the poor choice of the origin of the indices.

> While I agree about the points you made, you cant take the zeroth element out of your shopping bag, you take the first one.

where does the first centimeter / inch start in a physical ruler ?

You're both right.

You want to measure the distance from a starting point (zero), the person you're replying to wants to count/label things from a starting point (one).

The distance method doesn't work as well for picking items from a bag, and the counting method doesn't work as well for calculating offsets.

They can both work for arrays, so neither is wrong.

I'm mad at myself for getting dragged into this, but. Leaving aside the fact that array indexes are not continuous in the way ruler measurements are, what does it say that you just called it the 1st inch, not the 0th?

> Leaving aside the fact that array indexes are not continuous in the way ruler measurements are,

I have always seen a ruler as a discrete sequence of centimeters even if the physical object is continuous

> what does it say that you just called it the 1st inch, not the 0th?

but it's literally what I'm saying aha. The index of the first element is zero, even on basic household objects.

> I have always seen a ruler as a discrete sequence of centimeters even if the physical object is continuous

I have trouble believing this. Does this mean you think of a ruler as a tool to assign lengths (continuous) to discrete intervals, rather than as a tool to (perhaps imprecisely) measure the (continuous) length.

for me a ruler is something that tells me how many centimeters there is in whatever it is I want to measure - but maybe it's for linguistic reasons? e.g. in french I'd say "y'a combien de centimètres là?" when measuring something long with a tape meter and someone's help, which translates to "how many centimeters are there right now?" more or less

Except in Korea, where babies are considered to be age 1 starting at birth! https://en.wikipedia.org/wiki/East_Asian_age_reckoning#Korea

I wonder if it has something to do with a cultural perception of how life and the world in general is perceived. As in, "He's currently experiencing his first year of life" vs. "He has lived for one year", kind of "the journey" vs. "the destination". Seeing the present more than looking back the past. In the same line of thinking as "What you're doing" vs. "what you've done", or maybe even "making progress towards goals" rather than "accomplishments".

Seems like a healthier and maybe even more productive way to see the world. I don't know enough about Korea to say whether that has anything at all to do with the way they count ages, but I feel like it's an interesting thought regardless.

"Give me the 1st item" --> a[1]

"give me the 2nd item" --> a[2]

"how many items are in the array?" 5

"what is the index of the last item?" 5

I am used to 0-indexed and prefer consistency... yet there is an undeniable consistency to 1-indexed.

You're the person who brings back a dozen bottles of milk from the store when you see that they have eggs ;)

> "what is the index of the last item?" 5

Usually, the more interesting question is:

What is the index of the next item (when extending the array)? Which is 5 in 0-based indexing.

Is it? If you're doing low-level stuff maybe, but I really haven't done much of that so I'm not even sure I know what you mean by "extending" an array (presumably has something to do with allocating contiguous memory?) and I can't actually think of any situation off the top of my head where I would ever need "the last index + 1" what with array methods existing and all.

1-based vs 0-based indexing is such a tired controversy.

And a solved problem. Pretty much all the most popular languages have settled on zero-based indexing, who the hell cares what's more "correct".

What's closer to what programmers expect is a better choice. Being pedantic about "1 is actually better" helps no one.

It's the age old theory vs practice problem. Physicists vs engineers. Etc. This is why no one really cares about tau either.

0 based indexing was arbitrarily chosen due to the memory model of old programming languages.

If you have an array A with indices from S to T, you can use as its base address the address of A[S] minus S multiplied by sizeof(A[S]), then your address calculations are the same as with 0-based arrays. So I'd say it's a problem of a memory model of one old programming language, that is, C.

I strongly disagree. The decision was not in the least bit arbitrary. Language designers chose zero-based indexing because they believed its advantages outweighed the advantages of one-based indexing.

And it still does, in my opinion. In the end, no matter how high level your programming language is, you'll eventually be computing offsets to a base address in RAM using indexes that are zero-based. Having that be consistent at every level has great value.

It was arbitrary in that they chose to use a leaky abstraction to make it easier for themselves to make arrays using their memory model. The first person to do this could also have subtracted one from the user’s index to get the memory offset.

Or they could have saved themselves a CPU cycle every time they needed to index an array.

Don't get me wrong, non-zero-cost abstractions are great when they improve developer ergonomics commensurate to how much they cost. Garbage collection at the expense of GC overhead? Yes please. Classes and methods and inheritance at the expense of vtable lookups? Sure!

One-indexed arrays at the expense of either giving up the memory of the first item or always subtracting every index operation? Eh... I think I'd rather count from zero.

That's not what arbitrary means.

Arbitrary means there was no logical reason behind the choice, they just picked one. You can dislike the reason all you want. You can disagree with their choice, or think there are more important reasons to choose what you think they should have chosen, but that doesn't make their choice arbitrary.

Not really (the memory model of old machines was chosen too), but who cares?

0 based indexing is also slightly less prone to off-by-1 errors. But again, none of that matters more than keeping it standard.

Exactly, it’s an arbitrary cultural standard now.

That's the point I was making. It doesn't matter if it's arbitrary. The world runs on 0-based index languages. I couldn't care less to give that away for another arbitrary number. There is literally zero benefits and only downsides in getting used to it for any software engineer.

But software engineers aren’t the only ones who program these days. It’s true that many popular languages used by developers are 0-based, but the most popular language, Excel, is 1-based.

Non devs seem to prefer 1-based indexing in my experience. As a teacher of Java and C++ to new programmers, the 0 based nature of those languages is always a sticking point; it causes novice programmers to write incorrect code, which frustrates them and leaves them with the perception that programming is filled with arbitrary rules that are only there to confuse people. And they’re not so wrong, seeing as that even programmers here can argue endlessly about 1 vs 0 indexing with no definitive answer.

It was chosen because that's how pointer math works and nothing has happened to change that.

I can see some benefits of using 1-base, but on the whole, if 0-base has to be used anyway, I'd rather only use the necessary version so I'm not making off-by-one errors when switching languages.

Yes I understand pointer array math. The zero based indexing is great for that. It’s still a leaky abstraction to make the implementation correct. I’m also not saying it’s not my preferred way, but it’s not for any really good reason, it’s cultural.

Any fixed array range (at least starting index) is an example of worse is better, pushing the work onto the user of the language to map whatever the actual range should be into a 0-based (or 1-based) form. Different problems have different natural ranges, and you shouldn't have to write a routine that manages that for you. It results in one of several possible outcomes (when your range isn't naturally starting at whatever the language forces on you):

1. You don't help your own users, instead they have to know everywhere that they need to do `histogram[c - 'a']` to calculate the actual index (clutters the code, chance to forget something).

2. You do help your own users, but now they have to remember the function/procedure call to access it: `inc_histogram(c)`. Creating a plethora of setter/getter routines to gloss over this issue and bring performance back to straight array access.

3. You do help your own users, but they realize it's "just" an array and they can use `histogram[c-'a']` to access values (and set them directly) bypassing your API.

Better languages let you do this:

  histogram[c]++

Done.

If it was chosen for a reason, then it wasn't chosen arbitrarily.

> Pretty much all the most popular languages have settled on zero-based indexing.

Maybe true depending how you count, but there is plenty of code in languages with 1-based indexing too. My day-to-day these days is all MATLAB (1-based), except for the occasional optimized algorithm written in C. So I'm equally sensitive to being pedantic about "0 is actually better". They lend themselves well to different habits of reasoning. Switching back and forth can be painful if I don't take care.

This is perhaps an unintentionally ironic comment because the only languages that have any business at all being 1-based are MATLAB, Fortran, and Julia because they’re used to directly translate math notation which for series, sequences, and matrices is 1-based.

Lua’s one big niche is interfacing with 0-based C code in plugins and this horribly and completely unnecessarily painful because of its 1-based array design flaw.

It's amazing to me that the top comment on a post that has very little to do with indexing -- basically waves at the topic in passing -- is about indexing, AND that when it's pointed out that this is not a very scintillating topic of conversation in this day and age, all of the responses to that comment are just more pedantry about indexing. How does this trivial topic hold such fascination for people?

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

Sorry, no. Humans count from 1. That's just a basic fact reflected in the history of numbers, which at early stages often didn't treat 0 as a number, but as a special case. And if you would say "I counted zero red balls" most people around will find it an unusual wording. Normal way of saying it doesn't involve mentioning 0 at all: "It's empty", "There are no red balls" etc.

That special casing in English of no/none/empty is as much an artifact of lost germanic grammar cases in English as it is anything "natural" or inherent to how English speakers count.

I'm a member of multilingual family, and I'm inclined to insist it's not about Germanic grammar cases, because it's true for non-Germanic languages as well.

I just went "nearest ancestor up the stack" as a short hand, because the evolution of languages is a huge tree and a lot to talk about. If we want to get into it deeper, Proto-Indo-European had some truly fascinating grammar cases from what we think we've reconstructed of them. Most of the stuff that PIE did seems like "natural laws" simply because of how many modern languages we regularly see branched from it and how deeply rooted a tree in the language forest it is. But then we also have had chances to study non-PIE rooted languages and the "universals" are fewer than we think they are.

I mentioned history of numbers, and it starts not from PIE speaking peoples, so I'm a bit lost as for what exactly is your point.

I have no problems with people advocating from 1-based indexing, and I often disagree with EWD, but advocating for 1-based indexing with out referencing EWD's reasonably well known take[1] is going to damage the ethos of your argument.

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

Thank you so much. I love the end:

"In corporate religions as in others, the heretic must be cast out not because of the probability that he is wrong but because of the possibility that he is right."

I'll trust math more than human language evolution as a solid basis for indexing.

Also Julia's (default) 1-based indexing has become a mess.

0-based indexing is not universal in math either. We often index time from 0, but when we refer to components of a vector, we often index those from 1. For example, I'd write or see things like $\sum_{k=1}^N f(x_k)$ where $x$ is a vector. In these cases, 0-based indexing would look out of place.

Pretty much all programming languages designed for math are 1-based. Besides Julia, there's R, Mathematica (or "Wolfram language" as it is called these days), and Matlab.

I am curious, what mess did 1-based indexing create for Julia ???

My understanding (outside the community, I use it but am not hugely familiar with it) is that the 1-based indexing is the default, but you can select any range. Routines that assume 1-based indexing then break on anything that, well, isn't 1-based.

See: https://docs.julialang.org/en/v1/devdocs/offset-arrays/

Discusses how to generalize the code so it handles arbitrary ranges.

IMO 1 based and 0 based is a wash as to which is better, but the only definitive wrong answer is an arbitrary base. It may seem like a good compromise (just use whichever you prefer!), but it opens the door to a mars climate orbiter disaster waiting to happen.

Arbitrary indexing is fine as long as people are sane about how they do things and don't assume. In almost every language these days you can use this or something analogous:

  for x in some_collection

Which is great if you don't need the index, and if you do need the index then you want the equivalent of:

  for i in some_collection.range

  for i, x in some_collection.enumerated

Being forced to use 0-based or 1-based or even strictly integer-based indexing is the wrong thing. If you want to use characters/runes as your index you should be able to. If you want to use some enumerated type, you should be able to. And if you want some subrange of one of those, you should be able to.

> as long as people are sane about how they do things and don't assume.

Ime this expectation of developers doesn’t scale reliably. We can’t even trust engineers to keep feet and meters straight. Relying on conventions for correctness is a recipe for disaster.

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

Well, just like lua:

    > a={}

    > print(#a)

    < 0

I can't believe people are still seriously trying to argue this.

You count "things."

You don't count "not things."

Arrays are containers of things. Starting with 1 is overwhelmingly likely the thing that makes sense when using them.

Arrays aren't just used for counting though. For example, the origin in cartesian coordinates is "0,0" and not "1,1". Not to say that I disagree, I don't think I've come across a situation where 0-based indexing would have been better for me personally. But there are definitely a lot of situations where I can imagine it would be preferable, like pretty much whenever you're doing math with them.

I'd say containing things is just one function of arrays. The other arguably more important function is "naming" things using numbers.

Sure, but it seems like the latter isn't hurt by 1 indexing either, especially if the "names" are arbitrary, and if not, use associative?

Reply on news.ycombinator.com