3 ms·

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

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

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