Generalize BlockedUnitRange to element types besides Int

[mtfishman]

As of BlockArrays v0.16.39, BlockedUnitRange is hardcoded to only have an element type of type Int: https://github.com/JuliaArrays/BlockArrays.jl/blob/v0.16.39/src/blockaxis.jl#L50.

Would you be open to generalizing that to any integer type?

The UnitRange type in Julia allows any subtype of Real (https://github.com/JuliaLang/julia/blob/v1.10.2/base/range.jl#L400), I imagine allowing floating point element types adds quite a bit of complexity to the code, but supporting general integer types shouldn't be too hard to support. OneTo supports subtypes of Integer (https://github.com/JuliaLang/julia/blob/v1.10.2/base/range.jl#L449).

I hit this in the wild, where I want to use BlockedUnitRange with an element type that is a custom integer type, but the current code is too restrictive so I have to define my own type. It would of course be more convenient to just use the built-in type.

[dlfivefifty]

Yes!

I will say BlockedUnitRange was really just a prototype. I'm surprised its lasted 5 years without a redesign.

The way first is done is particularly problematic as it makes certain block structures not knowable at compile time. (I believe there's some @assert br.first == 1 scattered around where I work around this but I can't remember exactly where.) So if you are inclined to think out a better design that would be great.

[mtfishman]

Overall BlockedUnitRange has been quite nice, I like the interface and design.

Yes, I also noticed some issues with first. One issue is that, from what I can tell, if you want a BlockedUnitRange with first != 1 you can only do that right now with internal constructors. I thought the API for that might be broadcasting, such as blockedrange([2, 3]) .+ 1, but that loses blocking information, see #334. I believe when I tried using a BlockedUnitRange with first != 1 by constructing it manually with internal constructors, I came across a bug in findblock. I'll raise a separate issue for that.

Perhaps it warrants having both BlockedUnitRange and BlockedOneTo types, analagous to UnitRange and OneTo in base. Would you be open to defining an AbstractBlockedUnitRange supertype? Both of those could be subtypes of AbstractBlockedUnitRange.

An AbstractBlockedUnitRange supertype would also be useful in our use case, where we have blocked unit ranges where there is extra information associated with the blocks of the BlockedUnitRange. Specifically, we associate an irrep of a symmetry group with each block of the BlockedUnitRange, which is useful for representing tensors that are invariant under a group action, see for example https://arxiv.org/abs/1008.4774. Currently I am actually attaching that information to a custom integer type that I am storing in the lasts field of the BlockedUnitRange, but that design might be a bit too hacky. It may be a better design to define that as a custom type and share code with the standard BlockedUnitRange using an AbstractBlockedUnitRange supertype.

[dlfivefifty]

Ha I’m also interested in rep theory! I made a package NumericalRepresentationTheory.jl. Planning on writing something up for spectral methods for PDEs invariant to discrete symmetry groups, which also groups things by blocks.

Just saw your at flat iron! I’ve been meaning to visit Dan Fortunato, it would be great to chat about computational rep theory when I come. Or let me know if you are in London

[mtfishman]

Oh cool! Would be great to meet up at Flatiron or London. Let me know if you are visiting.

[mtfishman]

I will make a more narrow PR just generalizing BlockedUnitRange to accept other integer types, and we can discuss more ambitious plans around BlockedUnitRange elsewhere.

[mtfishman]

Closed by #255, #337, #348, #395.