Live data from Hacker News

Why numbering should start at zero (1982)

cs.utexas.edu

11–20 of 72 posts

Re: Why numbering should start at zero (1982)

#11
post #4

As usual, let me point out that Dijkstra's handwriting is a treat if you haven't seen it before. Here's the handwritten version of this note: https://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF

Wow. That is the best handwriting I've ever seen. Makes sense if you want people to read what you've written. I was baffled by the fact that my mathematics peers in uni had sich illegible hand writing, like they were doing it out of spite. I found I was correct more often when I took the time to articulate myself legibly, then again I concede I lost probably letter grade on average from all my exams because I ran out of time so often. Maybe that explains it.

Re: Why numbering should start at zero (1982)

#12
The discussion of how to denote the bounds of a sequence may be missing one consideration: Intuition from language. When speaking we articulate a range by stating the first and last permissible value. E.g. "Pick a number between one and ten". My point is understanding the length of the sequence is rarely as important as quickly grasping its bounds.

Re: Why numbering should start at zero (1982)

#14
In another thread last week, someone mentioned that 1-based indexing is more common in numerical analysis, so it has appeal for languages that are "math focused". Anyone have insight on that?

As far as I can recall, I've seen both 0 and 1-based indexing in statistics.

Re: Why numbering should start at zero (1982)

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

These would be peculiarities of the C programming language, not issues of typed integers or of expression ranges. Other, actually-strictly-typed languages will complain that 256 doesn't fit in a byte, or if 256 is a larger sized integer, that automatic comparisons between differently sized integer types is not allowed.

Yes, but my point was that the solution is to use a closed range instead; in this case, use `i <= 255` as the loop condition. Another solution, of course, is to widen the type of your induction variable.

Re: Why numbering should start at zero (1982)

#16
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 expect most counting for loops are one of two types: 'count from A to B inclusive' and 'count N numbers starting from M'.

We commonly have syntax for the first, or sometimes some variant of it designed to avoid the `-1' in the common case, at the cost of complicating some other cases. It's also common to have some rather over-general iterating mechanism called "for" that covers both, or tries to.

But I don't think I've ever seen anything special for the second, for some reason. And the iteration counter and the loop value could have different types - so you could count 128 int8_t values if you wanted. Though in most cases you'd just use it as a replacement for "for(i=m;i(One possible exception: the ancient 1980s computer I used as a boy had two syntaxes for saving blocks of memory. You could enter the range as "A B" (save from A to B inclusive), or as "M+N" (save N bytes starting from M).)

Re: Why numbering should start at zero (1982)

#17
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`.

Re: Why numbering should start at zero (1982)

#18

I see now

No it doesn't. Let's define the natural numbers to start with 42. Then the left side of the sequence 42, 43, 44 being represented as 41 It's clear that the author structured his essay carefully to avoid this exact assumption. He explicitly avoids considering whether the natural numbers start at 0 or at 1 until after he has chosen "a)".

Re: Why numbering should start at zero (1982)

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

Intuition is the name we give to what we learned early.

0 and 1 are both perfectly fine starting points. They both have advantages and disadvantages.

0 is more common since a lot of languages use C as a starting point in some fashion. C chose 0 because then it can create syntactic sugar for sequential memory access via pointers. Or arrays.

Re: Why numbering should start at zero (1982)

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

Post reply on HN