Open mtfishman opened 4 years ago
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.)
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".
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)).
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.
We should reevaluate the interface requirements for the
inds
object of theTensor
type, and try to make it as simple as possible. For example, if we assume theinds
object is indexable (which is true forDims
andIndexSet
) then it should just require having the elements ofinds
have adim
orblockdim
overload, instead of requiringinds
itself to have adim
orblockdim
overload.