support CartesianIndex offset

[johnnychen94]

The following usage could be helpful to deal with multi-dimensional arrays

OffsetArray(rand(4, 4), CartesianIndex(-1, -1))

I could do it later if you think this is a good idea.

[jishnub]

One may convert it to a Tuple in the constructor:

OffsetArray(rand(4, 4), Tuple(CartesianIndex(-1, -1)))

or extract the underlying Tuple as

OffsetArray(rand(4, 4), CartesianIndex(-1, -1).I)

I wonder if this calls for a specialized constructor?

[johnnychen94]

There are two behaviors wrt this as alternatives:

1. an convenient interface that is equivalent to Tuple: OffsetArray(A::AbstractArray, offset::CartesianIndex) = OffsetArray(A, offset.I)
2. offset the input array so that CartesianIndex(first.(axes(Ao))) == origin: CartesianIndex as an indicator of the origin of the offseted array.

When I opened I was thinking of the first semantic, but now I kind of prefer the second as it brings new functionalities. (and it reasons well to me) Thoughts?

[jishnub]

I like this idea, it removes the extra step required to compute the offset corresponding to a specific origin. I just wonder if this might be non-intuitive? Eg if broadcasting is required, it's been suggested that one should use Tuple(I) instead of a CartesianIndex I, as the former supports broadcasting. In this case one might expect Tuple(CartesianIndex(1)) .+ 0 and CartesianIndex(1) to behave identically when passed as arguments to the constructor. However, if I understand correctly, the former would have axes

julia> OffsetVector(ones(2), Tuple(CartesianIndex(1)) .+ 0) |> axes
(2:3,)

whereas the latter would have axes

julia> OffsetVector(ones(2), CartesianIndex(1)) |> axes
(1:2,)

Then again, a CartesianIndex is not supposed to be viewed as a container, but as a scalar entity in itself. This might allow us to use it in this context. Thoughts?

[johnnychen94]

Yes, this is a bit non-intuitive (or more accurately speaking, ambiguous), especially for those who are not familiar with the purpose of CartesianIndex. The logic behind reasons well to me.

it removes the extra step required to compute the offset corresponding to a specific origin

If we go with option 1, we'd still need such a helper, probably in other names.

I don't have a strong opinion here, ping @timholy for a triage

[timholy]

Interesting questions. I'd say that having CartesianIndex behaving differently from tuples would be a bit too confusing. But we could add a offset = ... keyword.

[timholy]

Sorry, finger slipped on the mouse pad and hit the wrong button. 😛

[jishnub]

I guess this confusion is avoided by using a different type that behaves analogous to a CartesianIndex? Eg we may define a struct Origin that wraps a Tuple and behaves as a CartesianIndex. This doesn't need to be as functional as a CartesianIndex as it is not to be used for indexing, merely for construction.

Taking this one step further, I wonder if it might make sense to have a special constructor where all the dimensions have the same origin. This might make the transition from zero-based indexing easier. Something like this might work:

julia> struct NBasedIndexing
       n :: Int
       end;

julia> function OffsetArrays.OffsetArray(arr::AbstractArray{<:Any,N}, indsorigin::NBasedIndexing) where {N}
           OffsetArray(arr, ntuple(d -> indsorigin.n - first(axes(arr, d)), Val{N}()))
       end;

julia> const ZeroBasedIndexing = NBasedIndexing(0);

julia> OffsetArray(zeros(3,2), ZeroBasedIndexing)
3×2 OffsetArray(::Array{Float64,2}, 0:2, 0:1) with eltype Float64 with indices 0:2×0:1:
 0.0  0.0
 0.0  0.0
 0.0  0.0

[johnnychen94]

This sounds like a good idea to me. I can play with it in the next couple of days.