indexing with static vector

[SimonDanisch]

I just tried to create a custom type inheriting from SVector and create a custom indexing behavior (getindex(A::AbstractArray, p::MyPoint)).
In theory, one just needs to overload:

Base.to_indices(A::AbstractArray, p::Tuple{<: Point}) = round.(Int, p[1].x)

To make this work, but because StaticArrays overloads getindex(A::AbstractArray, x::SVector) this doesn't work anymore.
Is this just wrongly overloading the getindex interface, or was there a reason to overload getindex directly?

[zygmuntszpak]

bump

[andyferris]

Hmm. I guess I need a bit more context on this one, please.

[zygmuntszpak]

The resolution of this issue would facilitate the implementation of multiple-view geometry algorithms.

In a nutshell, one may wish to define a type that represents homogeneous coordinates to facilitate various projective geometry operations. For example, one could like a pair of corresponding points in an image to be represented using homogeneous coordinates. The points themselves may have been estimated with sub-pixel precision so they are not whole numbers. However, one may still want to plot them in the image, or one may wish to extract features from pixels surrounding the particular point. Hence, it would be very convenient if one could define a way of indexing into an array---representing the digital image---using the homogeneous coordinates. One solution is to proceed as follows:

"""
HomogeneousPoint(x::NTuple{N, T})

In projective geometry [homogeneous coordinates](https://en.wikipedia.org/wiki/Homogeneous_coordinates) are the
natural coordinates for describing points and lines. 

For instance, the homogeneous coordinates for a planar point are a triplet of real numbers ``(u, v ,w)``, with ``w \\neq 0``. 
This triple can be associated with a point ``P = (x,y)`` in Cartesian coordinates, where ``x = \\frac{u}{w}`` and ``y = \\frac{v}{w}`` 
[(more details)](http://www.geom.uiuc.edu/docs/reference/CRC-formulas/node6.html#SECTION01140000000000000000).

In particular, the `HomogeneousPoint((10.0,5.0,1.0))` is the standardised projective representation of the Cartesian 
point `(10.0,5.0)`. 
"""
struct HomogeneousPoint{T <: AbstractFloat,N} 
    coords::NTuple{N, T}
end

# By overwriting Base.to_indices we can define how to index into an N-dimensional array
# given an (N+1)-dimensional [`HomogeneousPoint`](@ref) type. 
# We do this by converting the homogeneous coordinates to Cartesian coordinates
# and rounding to nearest integer.
# 
# For homogeneous coordinates of a planar point we return  
# a tuple of permuted Cartesian coordinates, (y,x), since matrices 
# are indexed  according to row and then column.
# For homogeneous coordinates of other dimensions we do not permute 
# the corresponding Cartesian coordinates. 
Base.to_indices(A::AbstractArray, p::Tuple{<: HomogeneousPoint}) = homogeneous_point_to_indices(p[1])

function homogeneous_point_to_indices(p::HomogeneousPoint{T,3}) where T 
    if  p.coords[end] == 1
        return round(Int,  p.coords[2]), round(Int, p.coords[1]) 
    else
        return round(Int,  p.coords[2] / p.coords[end]), round(Int, p.coords[1] / p.coords[end]) 
    end    
end

function homogeneous_point_to_indices(p::HomogeneousPoint) 
    if  p.coords[end] == 1
        return round.(Int, p.coords)
    else
        return round.(Int, p.coords ./ p.coords[end])
    end
end

However, ideally we would like to represent the coordinates of homogeneous points using a static vector for additional performance. I am in the process of writing various 'structure from motion/multiple view geometry' algorithms and would like to get the data structures right from the beginning if possible.

[andyferris]

Cool, thanks. A few thoughts:

1. StaticArrays provides the same interface behavior as Base but internally is quite different... and possibly always will be (well, hopefully not, but we're a long way from there right now).
2. When we have static unit ranges / Cartesian indices, we can probably share some more infrastructure with Base and LinearAlgebra and support offset arrays (which is part of what to_indices is about).
3. Since Base doesn't support interpolating indexing of arrays with non-integer indexing, we didn't think to support it here. I wonder - it seems the operation is a bit different to getindex and could perhaps use a different function?
4. Why don't you just define some getindex methods in your package? Do you want your package to compose well with StaticArrays but not depend on it? Or is there another requirement?

If someone is looking for some work to do, and wants to address the OP, we need to implement axes(::StaticArray) and keys(::StaticArray) to return some static ranges which are compile-time constants. Then we can implement to_indices and slices and so-on, and will also hopefully get you unblocked

[c42f]

I assume this is still an issue? The indexing code seems pretty gnarly and it might be possible to clean it up with improved use of to_indices.