4 ms·

It seems to be mostly about math, with the only mention of array indexing being that 0 looks nicer. "starting with 0, however, gives the nicer range 0 ≤ i < N.

It seems to be mostly about math, with the only mention of array indexing being that 0 looks nicer. "starting with 0, however, gives the nicer range 0 ≤ i < N. So let us let our ordinals start at zero" This doesn't seem to be much of an argument so I'm not even sure what to address.

StavrosK 8y ago
How would you do something like Python's `x[0:10] + x[10:len(x)]` in a 1-indexed way? [1:11] + [1:len(x)+1]? That's uglier.
- int_19h 8y ago
  You just make ranges end-inclusive, and then it's x[1:10] + x[11:len(x)]. The best of both worlds is when a language provides both end-exclusive and end-inclusive slice syntax, as in e.g. Nim: x[0..<10] is end-exclusive, and it's very clear that it is.
  - StavrosK 8y ago
    But then you no longer get back 10-1 elements, you get back 10-1+1.
    - thaumasiotes 8y ago
      So what? You're going to have off-by-one errors no matter what convention you adopt. Python glosses over it by providing the alternative syntax x[-1] for what you would otherwise have to write as x[len(x)-1]. But it's at least as valid to provide alternative syntax for inclusive ranges. And logically, if the first element of x is x[0], the last element should be x[-0], not x[-1]. Half-open intervals are appropriate when you're thinking of them as subspaces of a continuum. When you're thinking of them as subsequences of discrete elements, closed intervals are usually more natural. Ruby is the only language I know that really seems to have tried to address the problem, providing different syntax for every way you might want to take a subsequence from an array: x[5..8] # elements [5] through [8], including [8] x[5...9] # elements [5] through [9], excluding [9] x[5, 4] # four elements, starting at [5] If you were working in pure, pencil-and-paper mathematics, you'd choose whether to index a particular sequence from 0 or 1 based on what made your formula look nicer. Both are common. But that's not an approach I'd suggest for a programming language.
      - int_19h 8y ago
        One thing I would add - using negative indices to index from end is a bad idea in general, because you may inadvertently end up with a negative index as a result of a calculation that you expected to always be positive - and then instead of an out-of-bounds error, you get silent wrong behavior. IMO, it's better to have dedicated syntax for index-from-end, as part of the range syntax. Again, Nim does that: x[0..^1] (although unfortunately they didn't make it symmetric).
        thaumasiotes 8y ago
        > IMO, it's better to have dedicated syntax for index-from-end, as part of the range syntax. This is true, and note that my suggestion requires it -- the only way to distinguish x[-0] from x[0] is to have the parser do it; -0 and 0 are the same number.
        int_19h 8y ago
        I mean, you could technically distinguish between positive and negative zero, if your numbers are all floating points (like JS or Lua). But that would be even more of a horror show.
- joeyo 8y ago
  julia> x = collect(1:15)' 1×15 LinearAlgebra.Adjoint{Int64,Array{Int64,1}}: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 julia> x[1:10]' 1×10 LinearAlgebra.Adjoint{Int64,Array{Int64,1}}: 1 2 3 4 5 6 7 8 9 10 julia> x[11:end]' 1×5 LinearAlgebra.Adjoint{Int64,Array{Int64,1}}: 11 12 13 14 15 julia> x[11:length(x)]' # alternatively ... 1×5 LinearAlgebra.Adjoint{Int64,Array{Int64,1}}: 11 12 13 14 15
- Renevith 8y ago
  Others have already given examples of how languages with 1-indexed arrays handle this without awkwardness: end-inclusive ranges. I'll just add that end-inclusive ranges are the standard in natural language as well. For example: "Ages 2-4," "please read pages 16, 20 to 25, and 28 to 29," "1941-1945." 0-based indexing makes sense to me in C where arrays are just pointers and the index is an offset, and doing pointer math is a regular part of the programming experience. But most languages have come a long way from that, and collections such as arrays are much closer to a natural metaphor (a list of things). As such, natural ranges (inclusive) seem more appropriate to me.
deleted 8y ago
[deleted]

StavrosK 8y ago

How would you do something like Python's `x[0:10] + x[10:len(x)]` in a 1-indexed way? [1:11] + [1:len(x)+1]? That's uglier.

int_19h 8y ago
You just make ranges end-inclusive, and then it's x[1:10] + x[11:len(x)]. The best of both worlds is when a language provides both end-exclusive and end-inclusive slice syntax, as in e.g. Nim: x[0..<10] is end-exclusive, and it's very clear that it is.
- StavrosK 8y ago
  But then you no longer get back 10-1 elements, you get back 10-1+1.
  - thaumasiotes 8y ago
    So what? You're going to have off-by-one errors no matter what convention you adopt. Python glosses over it by providing the alternative syntax x[-1] for what you would otherwise have to write as x[len(x)-1]. But it's at least as valid to provide alternative syntax for inclusive ranges. And logically, if the first element of x is x[0], the last element should be x[-0], not x[-1]. Half-open intervals are appropriate when you're thinking of them as subspaces of a continuum. When you're thinking of them as subsequences of discrete elements, closed intervals are usually more natural. Ruby is the only language I know that really seems to have tried to address the problem, providing different syntax for every way you might want to take a subsequence from an array: x[5..8] # elements [5] through [8], including [8] x[5...9] # elements [5] through [9], excluding [9] x[5, 4] # four elements, starting at [5] If you were working in pure, pencil-and-paper mathematics, you'd choose whether to index a particular sequence from 0 or 1 based on what made your formula look nicer. Both are common. But that's not an approach I'd suggest for a programming language.
    - int_19h 8y ago
      One thing I would add - using negative indices to index from end is a bad idea in general, because you may inadvertently end up with a negative index as a result of a calculation that you expected to always be positive - and then instead of an out-of-bounds error, you get silent wrong behavior. IMO, it's better to have dedicated syntax for index-from-end, as part of the range syntax. Again, Nim does that: x[0..^1] (although unfortunately they didn't make it symmetric).
      - thaumasiotes 8y ago
        > IMO, it's better to have dedicated syntax for index-from-end, as part of the range syntax. This is true, and note that my suggestion requires it -- the only way to distinguish x[-0] from x[0] is to have the parser do it; -0 and 0 are the same number.
        int_19h 8y ago
        I mean, you could technically distinguish between positive and negative zero, if your numbers are all floating points (like JS or Lua). But that would be even more of a horror show.
joeyo 8y ago
julia> x = collect(1:15)' 1×15 LinearAlgebra.Adjoint{Int64,Array{Int64,1}}: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 julia> x[1:10]' 1×10 LinearAlgebra.Adjoint{Int64,Array{Int64,1}}: 1 2 3 4 5 6 7 8 9 10 julia> x[11:end]' 1×5 LinearAlgebra.Adjoint{Int64,Array{Int64,1}}: 11 12 13 14 15 julia> x[11:length(x)]' # alternatively ... 1×5 LinearAlgebra.Adjoint{Int64,Array{Int64,1}}: 11 12 13 14 15
Renevith 8y ago
Others have already given examples of how languages with 1-indexed arrays handle this without awkwardness: end-inclusive ranges. I'll just add that end-inclusive ranges are the standard in natural language as well. For example: "Ages 2-4," "please read pages 16, 20 to 25, and 28 to 29," "1941-1945." 0-based indexing makes sense to me in C where arrays are just pointers and the index is an offset, and doing pointer math is a regular part of the programming experience. But most languages have come a long way from that, and collections such as arrays are much closer to a natural metaphor (a list of things). As such, natural ranges (inclusive) seem more appropriate to me.

deleted 8y ago

[deleted]