Hi all.
I wanted to ask whether it was possible, and your opinion about it, to add a type node between AbstractMPS and the concrete types MPS and MPO. I mean something like this:
abstract type AbstractNSitesMPO{N} end
abstract type AbstractMPS <: AbstractNSitesMPO{1} end
abstract type AbstractMPO <: AbstractNSitesMPO{2} end
mutable struct MPS <: AbstractMPS
data::Vector{ITensor}
llim::Int
rlim::Int
end
Where the generic type now is AbstractNSitesMPO{N} which simply identifies how many site indices the tensors have. The functions currently written for MPS and MPO would be than written for the abstract types AbstractMPS and AbstractMPO. This would allow users to define different MPS types but still use the functions implemented in the ITensorMPS library.
The reason that makes me ask this is that I’m now in a situation where I could really use this, in fact I’m using tensors so big that the whole MPS does not fit in the ram, and since I’m using a server where I can’t use the swap, I had to use an hdf5 file as a pseudo swap, writing and retrieving the tensors from it, without storing the whole mps. The absence of this level of abstraction forced me to rewrite the functions I needed (like MPS-MPO contraction) while I could have simply defined the setindex! and getindex functions for my type and use the functions in ITensorMPS directly.
Thank you in advance for your time
In principle something like that is possible, though we are not currently making ambitious changes to ITensorMPS.jl since we are focusing on the development of ITensorNetworks.jl and the rewrite of ITensors.jl. You are of course free to try something like that in a fork of the package.
I would say that as a design principle, in ITensorNetworks.jl we are finding it is useful to have fewer tensor network types and simpler type hierarchies, for example right now we just have a general ITensorNetwork type with arbitrary connectivity and a TreeTensorNetwork type for tensor networks on trees, which includes MPS/MPO implicitly when the tree is just a path graph, and right now we aren’t distinguishing between states and operators using the type system (it is just implicit based on the number of indices on each tensor). When designing code, there is a nontrivial tradeoff between putting more information at compile time vs. leaving it at runtime, it is a difficult thing to get right without trying different code designs and seeing what leads to simpler and more maintainable code. We are finding that design is working pretty well so far but we may adjust as the need arises.
You are proposing making the number of indices a type parameter, which we have generally tried to avoid (in fact, the ITensor type takes a pretty extreme design choice of not being parametrized by the number of indices/number of dimensions, in contrast to every other Julia AbstractArray I know of). I think keeping the number of indices dynamic (i.e a runtime value) gives ITensors a lot of flexibility, and if you write good generic code you’ll find in general it is better to be agnostic about the number of indices and your code will be both simpler and accept more general inputs. At least, that is what we have learned (sometimes the hard way) from experience, and that design principle has been paying off a lot in my opinion, for example we have gone all in with that design approach in ITensorNetworks.jl and often the code there is both more general and simpler than the same code in ITensorMPS.jl.
Hi @mtfishman,
First of all, thank you for the detailed answer.
About the site indices, yes I was just taking AbstractArray as an example, but it was not the main point, what I wanted to point out is the possibility to implement functions (like the contraction etc.) for an abstract type instead that directly for a concrete type, allowing users to use those functions for other user defined types, but if I understood correctly this is already being done in ITensorNetwork, which is great.
The only thing I didn’t understand is if ITensorNetwork is going to replace ITensorMPS, since MPS and MPO are simple special cases of them, or if ITensorMPS would still be maintained after the release of ITensorNetwork
The goal is for ITensorNetworks.jl to eventually supersede/replace ITensorMPS.jl, but that won’t be for a while since we have a lot of ambitious things we still want to add to ITensorNetworks.jl and we want to make sure the design is solid before officially releasing it. Likely after that happens we will still maintain ITensorMPS.jl for a while, but focus more on fixing bugs rather than adding big new features. ITensorNetworks.jl involves a lot of new designs that are based on lessons we learned from ITensorMPS.jl about what designs work and don’t work, but those things are difficult to change in ITensorMPS.jl without being very disruptive to people, so it is easier for us to try new things in ITensorNetworks.jl while it is still a pre-release and not used by many external users.
Yes it makes a lot of sense.
Thank you again for the explanation