"Compressed" `CompositeBasis`

[akirakyle]

As discussed in #39, It would be great for CompositeBasis to efficiently store contiguous strings of N of the same basis tensored together so that Basis^N takes O(1). If something like that is implemented, then we can have something like const NQubitBasis(N) = SpinBasis(1//2)^N.

[amilsted]

I'm not sure I understand the utility of this. I think there are advantages to having an explicit list of bases in CompositeBasis. How about introducing AbstractCompositeBasis and having a subtype that does this "compression"?

[akirakyle]

I was imagining that once we define the interface for composite bases appropriately (#40 currently introduces the bases method to get the list of bases, but in #39 I'm working with implementing Base.getindex instead), then so long as we respect the interface, we can experiment with different ways of storing composite basis information depending on the use case and give options for more efficient ones.

I think this has utility in any package that subtypes AbstractState and AbstractOperator, and hence should implement the basis method, and furthermore has a representation which scales is efficiently with the number of modes involved (such as Gabs or QuantumClifford). Then the overhead of keeping an explicit list of bases might not be so negligible.

I guess the question is whether it makes sense to have some AbstractCompositeBasis type or just have a method interface that every basis must conform to which allows for querying it's tensor decomposition and thus one could view every basis as essentially a composite basis? For example we could add a .modes field to every basis so that no CompositeBasis is necessary to express homogeneous tensor products of the same basis.