Try to simplify the overload requirements for inds

[mtfishman]

We should reevaluate the interface requirements for the inds object of the Tensor type, and try to make it as simple as possible. For example, if we assume the inds object is indexable (which is true for Dims and IndexSet) then it should just require having the elements of inds have a dim or blockdim overload, instead of requiring inds itself to have a dim or blockdim overload.

[emstoudenmire]

Agreed, yes. Then I guess one immediate advantage is that something like a Vector{Index} or a Vector{MyType} where MyType is some type from an external library could work as the indices of a Tensor? (Btw I kept wanting to call it an “NDTensor” when writing the paper.)

[mtfishman]

Yeah, though it wouldn't be a good idea to use Vector as the storage, since that is not statically sized so the order of the Tensor wouldn't be inferable. SVector or MVector would be better examples of other storage to use. I was considering that we could limit the storage to be NTuple{N,IndT}, since Tuple is a pretty generic format that statically sized containers are easily converted to (for example SVector, MVector and IndexSet all have costless conversions to Tuple). This could be handled easily since the tensor(::ITensor) conversion would convert the IndexSet to an NTuple{N, Index}, and the itensor(::Tensor) would convert it back to an IndexSet (that case is already handled now). It could make some of the code in NDTensors simpler, since now it needs to generically account for any storage type that inds could have which makes for some ugly code in certain places. I don't expect people would be coming up with crazy storage types to use for inds that couldn't just be converted to a Tuple.

I guess "NDTensor" could be used interchangeably with "NDTensors", like we will use "ITensor" interchangeably with "ITensors". In retrospect we could have called the package "NDTensor", since it doesn't clash with any actual type names in the package, but it just seemed natural to have the symmetry with "ITensors".

[emstoudenmire]

That’s interesting about sticking just to NTuple. It makes a lot of sense if the code is having to do contortions to be overly generic.

Actually, I didn’t mean about renaming the package to NDTensor.jl - NDTensors is a good name -just I kept thinking the actual type is called NDTensor (so like T = NDTensor(3,4)).

[mtfishman]

Ah I see. It might not be a bad idea for a name, since Tensor may clash with other packages. Some of the type names are already getting quite long as they are, though.