Generalization of AbstractRange?

[chakravala]

Please see my post on discourse about generalizing AbstractRange objects to SVector inputs for multidimensional ragnes.

https://discourse.julialang.org/t/orthotope-grid-type-generalization-of-abstractrange/45072/3?u=chakravala

Either, this needs to be added to StaticArrays package to define the : constructor method without type piracy, or I need to add it to Grassmann and use my own custom vector input types for it.

Most likely, I’ll just add it to Grassmann since that has the least friction workflow for me, but if anyone else is interested, I can consider making a pull request to StaticArrays package.

[mateuszbaran]

What benefit does it have over the product iterator: https://docs.julialang.org/en/v1/base/iterators/#Base.Iterators.product ?

[chakravala]

Didn't know about that before, but it seems the product iterator returns tuples, which is the wrong type.

[andyferris]

Yeah - it would be nice if Iterators.product accepted a function, like map.

[stev47]

Julia base often uses NTuple{N,AbstractRange{T}} (at least for integer T) and for use with indices there is the wrapper CartesianIndices that supports range syntax CartesianIndex(1,1):CartesianIndex(3,3) already. A dedicated Orthotope type could improve memory layout compared to these, though I don't see a reason why it needs to use SVectors instead of Tuples internally if it's just a multidimensional generalization of AbstractRange{T} in julia base.

[chakravala]

In my most recent post on the discourse link, I shared my implementation variant of it. It is now in Grassmann.jl so I actually use the type `Grassmann.Chain{V,1}` which is a grade 1 vector space element type used in my algebra. I suppose the `Orthotope` struct could be a tuple, but since the `Orthogrid` iterator is supposed to return vector space elements, an `SVector` would also be appropriate. Anyways, I am quite happy with my implementation of it now. chakravala/Grassmann.jl@02472f0 ```julia julia> using Grassmann; basis"3" (⟨+++⟩, v, v₁, v₂, v₃, v₁₂, v₁₃, v₂₃, v₁₂₃) julia> OG = Chain(1.0v1):(0.2v2+0.2v3):(1.0v1+v2+v3) (1.0v₁ + 0.0v₂ + 0.0v₃):(0.0v₁ + 0.2v₂ + 0.2v₃):(1.0v₁ + 1.0v₂ + 1.0v₃) ```

…

On Fri, Aug 21, 2020, 4:40 AM Stephan Hilb ***@***.***> wrote: Julia base often uses NTuple{N,AbstractRange{T}} (at least for integer T) and for use with indices there is the wrapper CartesianIndices that supports range syntax CartesianIndex(1,1):CartesianIndex(3,3) already. A dedicated Orthotope type could improve memory layout compared to these, though I don't see a reason why it needs to use SVectors instead of Tuples internally if it's just a multidimensional generalization of AbstractRange{T} in julia base. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#816 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEMFOECMZVBSTPK6WYEQ5X3SBYXH3ANCNFSM4QBYNPLQ> .

[chakravala]

Regarding the types for the Orthotope field types, another reason for making them the same as the vector space element types is that simplifies methods and calculations used for generating the actual elements of the Orthogrid. For example,

function getindex(t::Orthogrid{V},i::Vararg{Int}) where V
     Chain{V,1}(value(t.x.min)+(SVector(i)-1).*step(t))
end

Thus, the Orthotope bound values can simply be added and subtracted as algebraic elements to generate grid points.

[stev47]

Well, if you have an x::NTuple{N,AbstractRange{T}} it is just

mygetindex(x, i...) = getindex.(x, i)

(or similar, if you are wrapping that type) without reimplementing ranges. Julia does not seem to vectorize this access though, which would be one of the main reasons of having a dedicated type with better memory layout I think.

[c42f]

So is the main thing that it'd be desirable to iterate StaticArrays rather than Tuples vs the other options?

I'm in two minds about this. It seems handy, but also potentially obscure and non-obvious compared to using CartesianRange?

[chakravala]

This issue can be closed as far as I am concerned at this point, since I am satisfied with my Orthogrid type in Grassmann now, so the rest is entirely up to you.

[c42f]

Ok, let's close this. Thanks for the discussion!