Repository navigation
Generalization of the CTMRG state type #115
Description
Activity
Just to make a comment here, I think there are two separate issues you are touching upon.
The first is about data structures, in the sense of how we actually lay out the data as julia structs. There are many options, using tuples or custom structs, and my guess is that the performance implications are completely negligible, so I would just choose the thing that is most easy to interpret as a human. In other words, whatever is the most intuitive for each specific instance should be fine.
A second point is about designing functions. Here, it is a very common pitfall to think in terms of abstract types and type hierarchies, which is I fear somewhat the direction this question is pushing towards. Very often, prematurely restricting the type signature of functions leads to bad code architectures, since you then are effectively designing code around objects. Julia often shines best by not thinking about the data structures at all, and simply ducktyping everything. This means that rather than thinking about what types of arguments the CTMRG routine should accept, it is a lot better to think about what functions the arguments should support.
TLDR: instead of trying to fit everything into abstract types, I would focus more on trying to avoid specializing methods as much as possible, especially the higher level parent methods and only doing that whenever the actual layout of an object is known, writing concrete implementations for leaf methods. That way, we can decide on future additions in the future, and simply implement only the leaf methods whenever needed.
- locked and limited conversation to collaborators
on Jan 12, 2025
Currently, CTMRG only runs on
InfinitePEPSas its state type, and with #111 also onInfinitePartitionFunctions. However, all CTMRG contractions as well as the sparse storage structs in principle support more general objects, such as PEPS-PEPS or PEPS-PEPO-PEPS sandwiches.In order to generalize the state type that is specified by the user and passed on to
leading_boundarywe need to agree on a design. Looking at the implementation of CTMRG, it is clear that the type ofstateneeds to support indexing operations and rotations. I think there are at least two options:PEPSSandwichandPEPOSandwichtype. Here the question would be if they should be subtyped as anInfiniteSquareNetwork- this would however somehow create a circular hierarchy in its current state.InfiniteSquareNetworksto represent the sandwiches, e.g.Tuple{InfintePEPS,InfinitePEPS}, and define indexing methods such asgetindexon them.Another thing to consider is to relax the
InfiniteSquareNetworkinterface such that it is understood as an interface which states that can be contracted using CTMRG should support. This would e.g. mean getting rid of the math and OptimKit operations.See #111 for further comments.