Why numbering should start at zero (1982) • Hacker News Board

Re: Why numbering should start at zero (1982)

#31

Post by [deleted] » Thu, Aug 16, 2018, 4:43 PM UTC

OscarCunningham wrote: post #29

Sharlin wrote: 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.

[deleted]

Re: Why numbering should start at zero (1982)

#32

Post by js2 » Thu, Aug 16, 2018, 4:44 PM UTC

The part of his argument I find most convincing is his first remark that in practice convention (a) has the fewest programming errors.

Aside, Antony Jay cowrote of Yes Minister and Yes, Prime Minister.

https://en.wikipedia.org/wiki/Antony_Jay

I'm familiar with the shows but didn't recognize his name.

Re: Why numbering should start at zero (1982)

#33

Post by toast0 » Thu, Aug 16, 2018, 4:45 PM UTC

Sharlin wrote: post #15

moron4hire wrote: post #3

Earlier quoted context omitted.

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.

But that doesn't work here either -- 255 + 1 = 0, and 0 <= 255, so you still loop forever.

Re: Why numbering should start at zero (1982)

#34

Post by perl4ever » Thu, Aug 16, 2018, 4:47 PM UTC

rhacker wrote: post #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 stud…

  my @arr = (1, 2, 3);

  for my $i ($[...$#arr) {
     ...
  }

It is however, advised not to change $[.

Re: Why numbering should start at zero (1982)

#35

Post by zAy0LfpBZLC8mAC » Thu, Aug 16, 2018, 4:47 PM UTC

School-Cotton wrote: post #17

jkabrg wrote: 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`.

In other words: You noticed that array offset operations have an additive structure, and as the neutral element of addition is the zero, the only sane way to do indexing is to start at 0.

Re: Why numbering should start at zero (1982)

#36

Post by Serow225 » Thu, Aug 16, 2018, 4:47 PM UTC

SiempreViernes wrote: post #26

IshKebab wrote: post #9

Earlier quoted context omitted.

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.

Yes probably reshape would be the natural MATLAB way to do it. Under the hood it doesn't change the memory allocation of the mxArray, just the metadata -- so the reshape takes virtually no time. But if you wanted to do the loop like that, I think you could simplify that to 1:10:end , btw. Also there is a blockproc function that will do it for you, you just pass in the chunk size and a function handle to 's', but it's in the Image Processing toolbox

Re: Why numbering should start at zero (1982)

#37

Post by SiempreViernes » Thu, Aug 16, 2018, 4:50 PM UTC

bena wrote: post #19

jkabrg wrote: 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.

No, C got that from B that got it from BCPL, which has that notation to compile faster: http://exple.tive.org/blarg/2013/10/22/citation-needed/

Re: Why numbering should start at zero (1982)

#38

Post by krylon » Thu, Aug 16, 2018, 4:55 PM UTC

chrispeel wrote: post #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 ind…

I remember reading a funny quote that the obvious compromise between 1- and 0-based indexing was 0.5, and that it was dismissed without proper consideration. Unfortunately, I do not remember where I read that or who wrote/said it. :(

Re: Why numbering should start at zero (1982)

#39

Post by jacobolus » Thu, Aug 16, 2018, 4:55 PM UTC

jkabrg wrote: 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…

> Indexing backwards from the "end". Your language can always add an `end` keyword like Matlab does, and this stops

Having used Matlab a bunch, in practice this sucks, because “end” is treated as this weird special case in the language grammar, and many reasonable and convenient expectations of syntax that should work turn out not to. Folks writing complicated Matlab projects end up needing to work around it, and the workarounds are brittle and confusing.

Using negative integers is a whole lot easier to reason about and work with.

Everyone learns in grade school how to do arithmetic with negative integers (adopted by European mathematicians in the 17th century). Even Matlab experts don’t always understand Matlab ‘end’ arithmetic.

Re: Why numbering should start at zero (1982)

#40

Post by notduncansmith » Thu, Aug 16, 2018, 4:55 PM UTC

throwawaymath wrote: post #24

School-Cotton wrote: post #17

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…

> we can talk about a_3 by calling it the third term

It's still the "third" term. People commonly refer to the "zeroeth" term in a list as the "first" term, the "first" term as the "second", and so on. Admittedly, the usefulness of "zeroeth" depends on how often you think about the mechanics of array traversal, and that's probably not often if you don't program computers.