5 ms·

I understand the argument, but when the default disagrees with your override, there's almost always an impedance mismatch and some pain. It's like being left h

I understand the argument, but when the default disagrees with your override, there's almost always an impedance mismatch and some pain. It's like being left handed when 99% of the interfaces in the world assume you're right handed. People argue that zero-based is incidental, and that 1-based is the right way because of it's long history in mathematics notation. I would argue that 1-based is incidental, and that zero-based is better most of the time for modern math and computer architectures.

KenoFischer 8y ago
I can understand why you might get the impression, but I'd encourage you to try out julia and see that we're really quite good at using index-agnostic abstractions, so most code doesn't care what your arrays are indexed with. If a certain set of indices make sense in your domain (0-based for FFTs as you say, symmetric indices about the original for image filters, 1-based for just regular lists of things, etc), just use it, and it'll be convenient interactively, but most library code doesn't really think about it that much.
- civility 8y ago
  I'll (cautiously) take your word that this works transparently when I supply arrays as arguments to a library function. However, what does the library function return to me as arrays it allocates? What if I do an outer product of two arrays with different base indices? Whatever your answer, I suspect it is more cognitive overhead to remember than "always 1 based" or "always 0 based".
  - KenoFischer 8y ago
    > However, what does the library function return to me as arrays it allocates? Depends what the library function does of course. If it's shape preserving (e.g. if it's a map over the array), it'll generally preserve the axes of the input array. > What if I do an outer product of two arrays with different base indices? You'll get an offset array indexed by the product of the axes of the input: julia> A = OffsetArray(1:3, 0:2) OffsetArray(::UnitRange{Int64}, 0:2) with eltype Int64 with indices 0:2: 1 2 3 julia> B = 4:6 4:6 julia> A*B' OffsetArray(::Array{Int64,2}, 0:2, 1:3) with eltype Int64 with indices 0:2×1:3: 4 5 6 8 10 12 12 15 18 > Whatever your answer, I suspect it is more cognitive overhead to remember than "always 1 based" or "always 0 based". Sure, but the real point here is that in most situations, you don't actually care what the axes are, because you use the higher level abstractions (e.g. iteration over elements or the index space, linear algebra operations, broadcasts, etc.), which all know how to deal with arbitrary axes. The only time you should ever really have to think about what your axes are is if there's some practical relevance to your problem (OffsetArrays are used heavily in the images stack).
  - rrock 8y ago
    Not really. Imagine taking a rectangular region of interest from an image. With offset arrays, you can use the original indices if that suits you. I’d say that’s strictly better than using always zero based offsets.

KenoFischer 8y ago

I can understand why you might get the impression, but I'd encourage you to try out julia and see that we're really quite good at using index-agnostic abstractions, so most code doesn't care what your arrays are indexed with. If a certain set of indices make sense in your domain (0-based for FFTs as you say, symmetric indices about the original for image filters, 1-based for just regular lists of things, etc), just use it, and it'll be convenient interactively, but most library code doesn't really think about it that much.

civility 8y ago
I'll (cautiously) take your word that this works transparently when I supply arrays as arguments to a library function. However, what does the library function return to me as arrays it allocates? What if I do an outer product of two arrays with different base indices? Whatever your answer, I suspect it is more cognitive overhead to remember than "always 1 based" or "always 0 based".
- KenoFischer 8y ago
  > However, what does the library function return to me as arrays it allocates? Depends what the library function does of course. If it's shape preserving (e.g. if it's a map over the array), it'll generally preserve the axes of the input array. > What if I do an outer product of two arrays with different base indices? You'll get an offset array indexed by the product of the axes of the input: julia> A = OffsetArray(1:3, 0:2) OffsetArray(::UnitRange{Int64}, 0:2) with eltype Int64 with indices 0:2: 1 2 3 julia> B = 4:6 4:6 julia> A*B' OffsetArray(::Array{Int64,2}, 0:2, 1:3) with eltype Int64 with indices 0:2×1:3: 4 5 6 8 10 12 12 15 18 > Whatever your answer, I suspect it is more cognitive overhead to remember than "always 1 based" or "always 0 based". Sure, but the real point here is that in most situations, you don't actually care what the axes are, because you use the higher level abstractions (e.g. iteration over elements or the index space, linear algebra operations, broadcasts, etc.), which all know how to deal with arbitrary axes. The only time you should ever really have to think about what your axes are is if there's some practical relevance to your problem (OffsetArrays are used heavily in the images stack).
- rrock 8y ago
  Not really. Imagine taking a rectangular region of interest from an image. With offset arrays, you can use the original indices if that suits you. I’d say that’s strictly better than using always zero based offsets.