Live data from Hacker News

Why numbering should start at zero (1982)

cs.utexas.edu

21–30 of 72 posts

Re: Why numbering should start at zero (1982)

#21
post #7

Starting at 1 is more intuitive, and therefore IMO better. Regarding some of the advantages of zero-based: - Indexing backwards from the "end". Your language can always add an `end` keyword like Matlab does, and this stops being an advantage. - Indexing cyclically using modular arithmetic. Yes, this is an advantage. Albeit a rare one for me. I commit less off-by-one errors with 1-based, and I don't have to double-che…

[deleted]

Re: Why numbering should start at zero (1982)

#22
I always like to point to the Julia package TwoBasedIndexing (https://github.com/simonster/TwoBasedIndexing.jl/) which is IMHO provides the very best way to index an array. Yes, Julia defaults to 1-based indexing, and allows zero-based indexing (https://github.com/JuliaArrays/OffsetArrays.jl) or indeed whatever sort of indexing you want, yet I think the world is going to eventually come around to THE ONE TRUE indexing scheme of being two-based.

:-)

Re: Why numbering should start at zero (1982)

#23
When I was learning QBasic some billion years ago I recall that I was happy with arrays generally starting at 1 (even though this is user specified in Basic). When I learned C I initially wasn't thrilled about re-learning arrays, but eventually grew to only like 0-based arrays.

I'm thinking this is like people who drink coffee will cite studies saying it is good for you, and people who hate it will cite opposite studies.

Re: Why numbering should start at zero (1982)

#24
post #7

Starting at 1 is more intuitive, and therefore IMO better. Regarding some of the advantages of zero-based: - Indexing backwards from the "end". Your language can always add an `end` keyword like Matlab does, and this stops being an advantage. - Indexing cyclically using modular arithmetic. Yes, this is an advantage. Albeit a rare one for me. I commit less off-by-one errors with 1-based, and I don't have to double-che…

> Starting at 1 is more intuitive, and therefore IMO better. This is totally subjective. Starting at 0 is more intuitive to me. My intuition is very simple. `x` is the name of some memory location. `x[k]` is the location `k` spaces away from `x`.

I can agree that's intuitive, but I'd like to point out that's not quite the same thing as numbering a sequence.

If we have a sequence a_1, a_2, a3, ... we can talk about a_3 by calling it the third term. If we have a sequence a_0, a_1, a_2, ..., the third term is actually a_2.

Whether or not we should index starting at 0 or 1 is probably dependent not only on intuition, but the application at hand. For most analytic purposes it's generally more useful to talk about the nth term, and we don't need to know a specific number to reason about the distance between any two indices. For other purposes, such as programmatic ones, it is useful to know e.g. the traversal distance between two items in a list.

In my opinion it's best to first consider whether you're working in more of a mathematical or programmatic context, and then secondarily who will have to read it later on.

Re: Why numbering should start at zero (1982)

#25

The initial sentence has always bothered me > To denote the subsequence of natural numbers 2, 3, ..., 12 without the pernicious three dots What's so pernicious about them? I don't see it. It seems like a clear and intuitive way to communicate a sequence to me. I even wrote a little range generator in JS to explore parsing declarations like that. https://github.com/chrisbroski/iterize It seems to work fine.

That notation is ambiguous. It doesn't cause a problem for humans since we can infer the correct meaning from the context, but it would for computers.

For example, does 3, 5, ... 11 mean the odd numbers between 3 and 11 inclusive, or the primes between 3 and 11 inclusive?

Re: Why numbering should start at zero (1982)

#26
post #9
post #7

Starting at 1 is more intuitive, and therefore IMO better. Regarding some of the advantages of zero-based: - Indexing backwards from the "end". Your language can always add an `end` keyword like Matlab does, and this stops being an advantage. - Indexing cyclically using modular arithmetic. Yes, this is an advantage. Albeit a rare one for me. I commit less off-by-one errors with 1-based, and I don't have to double-che…

Matlab uses 1-based indexing. I've used it extensively and it was definitely a bad move. One particularly annoying example is splitting an array into blocks, e.g. for i = 1:numel(s) foo(s[i]) end That is fine, but what if you want to process in blocks of N? Now you have to do: for i = 1:(numel(s)/10) foo(s[(i-1)*N + (1:N)]) end Ugh no thanks. This is as simple as it gets too. For more complex array manipulation... en…

I would reshape s since foo would anyway be vectorized.

You could also do

for i = 1:10:length(s)

   foo(s(i:i+9))
endfor

With numpy the 9 turns into a 10 by the design choice that s[a:b] only goes to s[b-1], this is sometimes convenient, and sometimes it costs a +1.

Re: Why numbering should start at zero (1982)

#27

Earlier quoted context omitted.

> Starting at 1 is more intuitive, and therefore IMO better. This is totally subjective. Starting at 0 is more intuitive to me. My intuition is very simple. `x` is the name of some memory location. `x[k]` is the location `k` spaces away from `x`.

I can agree that's intuitive, but I'd like to point out that's not quite the same thing as numbering a sequence. If we have a sequence a_1, a_2, a3, ... we can talk about a_3 by calling it the third term. If we have a sequence a_0, a_1, a_2, ..., the third term is actually a_2. Whether or not we should index starting at 0 or 1 is probably dependent not only on intuition, but the application at hand. For most analytic…

You don't have to talk about memory locations, or computers at all, for the intuition to work. `a_2` is two spaces away from the beginning of the list.

The fact that our ordinal numbers are closely connected with the off-by-one cardinal numbers (e.g., "third", meaning the element of a sequence in position 2, is closely etymologically related to the word "three") is an unfortunate defect of language.

Re: Why numbering should start at zero (1982)

#28

The initial sentence has always bothered me > To denote the subsequence of natural numbers 2, 3, ..., 12 without the pernicious three dots What's so pernicious about them? I don't see it. It seems like a clear and intuitive way to communicate a sequence to me. I even wrote a little range generator in JS to explore parsing declarations like that. https://github.com/chrisbroski/iterize It seems to work fine.

I _think_ he calls them pernicious because of the ambiguity.

2,3,4,12 is also a "subsequence of natural numbers", but probably not what was meant by 2,3,...,12. You might counter that ... means the complete subsequence, but what do you mean by "complete"?

If I write 2,4,6,8,...,24, you probably want the ... to mean 10,12,14,...[1], not 9,10,11,12,...

Basically by the time you make ... precise, you are better off just writing the mathematical notation.

[1] See what I did there? ;)

Re: Why numbering should start at zero (1982)

#29
post #2

There's one important use case for Dijkstra's alternative (c), that is, an interval closed at both ends. That is when your set has a maximum element and you want to be able to express an interval including the maximum. This is, of course, important in any programming language whose basic integer types have a bounded range. For instance, the following loop in C never halts: for(uint8_t i = 0; i What's even worse, the…

I don't quite understand what you're saying. If you change the code to

    for(uint8_t i = 0; i 
then it still doesn't halt.

Re: Why numbering should start at zero (1982)

#30

The initial sentence has always bothered me > To denote the subsequence of natural numbers 2, 3, ..., 12 without the pernicious three dots What's so pernicious about them? I don't see it. It seems like a clear and intuitive way to communicate a sequence to me. I even wrote a little range generator in JS to explore parsing declarations like that. https://github.com/chrisbroski/iterize It seems to work fine.

That notation is ambiguous. It doesn't cause a problem for humans since we can infer the correct meaning from the context, but it would for computers. For example, does 3, 5, ... 11 mean the odd numbers between 3 and 11 inclusive, or the primes between 3 and 11 inclusive?

No, it is ambiguous for humans too as evidenced by the gazillions of problems of the form "N1, N2, N3, what number comes next?".

Just decide on some rule for how decide and let people make their own standard if they don't like it.

Post reply on HN