StaticRanges

General Usage Performance
,
1

I’m working on what may turn into a package.

https://github.com/Tokazama/StaticRanges.jl

Conceptually it’s fairly simple. It has a one type StaticRange and a convenient interface through srange (which is meant to act like range from base). I shamelessly copied code from base julia to make it work. My current benchmarks (which litter the README page) show it may be a good alternative if you need to use the same set of indices many times.

Because this was more of a byproduct of something else I’m working on I don’t have a clear vision of the best way to handle it (package it, contribute to StaticArrays, leave it for my posterity to marvel at, etc.), but after benchmarking this morning I thought some people might benefit from it. I imagine there could be problems with ambiguities due to every field of ranges being part of the type’s parameterization, so it may serve as nothing more than an interesting idea.

2

We have some related stuff in StaticArrays; did you see the SOneTo type, for instance?

julia> using StaticArrays

julia> axes(@SMatrix [1 2;
                      3 4;
                      5 6])
(SOneTo(3), SOneTo(2))

Though SOneTo is a subtype of AbstractUnitRange rather than StaticArray. CC @andyferris

4 Likes
3

Yes. But I specifically needed steps in my ranges.

4

Yeah, I’m not suggesting you’re duplicating functionality, just pointing out some similarities with existing code. The functionality you’ve got looks useful and it probably makes sense to put it in StaticArrays. Though we’re already maintaining a rather large amount of code in that package because there’s statically sized equivalents of large parts of stdlib/LinearAlgebra as well as the Base abstract array functionality. It feels like it’s getting a little unweildy :wink:

One thing I noticed is that your range type is not a subtype of AbstractRange which makes sense because you’d like it to subtype StaticVector, which is obviously not a range. That does mean you might have to duplicate some functionality which is automatically provided for AbstractRange? There’s not really any good solution to that without formalized traits or interfaces in the language.

5

My guess would be that the few default behaviors AbstractRange provides would want to be specialized in any case. The biggest things you’d be giving up would be functions limited to AbstractRange — which I think are very few beyond AbstractUnitRange’s use as an axis type.

6

Yeah, this is why I didn’t bring it up over there. This is kind of just thrown together and may get some TLC if I keep finding urgent uses for it.

I tried subtyping AbstractRange but found little immediate benefit. It does make logical sense but that only seemed to inherit an error when I had yet to define step. By subtyping StaticVector I believe it inherits some nice boosts in indexing under the hood.

I haven’t yet ran into any issues with this but I also haven’t tried to push it that far. I’ve thought about defining something like StaticIndices but I haven’t investigated how much effort that would take to make useful. I assume it would be pretty involved.

2 Likes
7

Been putting together more organized benchmarks and finding a more appealing way of presenting it. Also updated the github repo.

indexing
indexing694×346 6.87 KB

The four groups are the structures being indexed into and the labels at the bottom describe the structure used to perform the indexing. The “by_nd_*” is performing indexing along each axis instead of just linearly. I will probably replace these as I finish up some multidimensional indexing.