You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have for a long time wanted to change the way our mps are constructed, and I finally started to have a first go at the idea I had in mind.
Disclaimer: everything is up for debate, including names and functionality.
The main idea is that I want to mimic what Base and TensorKit do for their constructors, which basically boils down to having
rand([T], structure) -> output
In order to achieve this, I therefore added some structure to dispatch on, which I tentatively named MPSManifold.
This is just a glorified collection of all of the spaces, but I would argue that it nicely organizes a bit more of the logic surrounding spaces away from the logic concerning the actual constructors.
The updated workflow would now be:
I like that it separates out some code logic, especially surrounding the "full-rank-ness" of MPS, and I like the syntax, and I love that we no longer have a million weird constructors that would have to be supported, but before I go in and update the docs, and do the same for the InfiniteMPS, I would like some feedback.
Does this make sense? Is it too convoluted? Do you think it is an improvement?
It would be fairly straightforward to add various utility functions to this interface as well, such as vcat, repeat, ...
I'm definitely in favor of streamlining the way (in)finiteMPS objects are created. I also like the idea of making it very similar to other construction methods in the ecosystem like rand(scalartype, abstractwhateverspace). I do like the fact that there are a multitude of ways to create an MPS at the moment, like giving a physical dimension, max virtual dim. and a length for example. These are all very easy to parse into the standard FiniteMPSManifold form though.
On a related note:
Creating a specific state instead of just a random one is too complicated at the moment in my opinion.
Oftentimes I want to start my simulation from some computational basis state, or from another simple product state and making this by hand is rather cumbersome. Some functionality to make some simple states instead of just random ones would be something i'd like very much and would definitely want to help with.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I have for a long time wanted to change the way our mps are constructed, and I finally started to have a first go at the idea I had in mind.
Disclaimer: everything is up for debate, including names and functionality.
The main idea is that I want to mimic what
BaseandTensorKitdo for their constructors, which basically boils down to havingrand([T], structure) -> outputIn order to achieve this, I therefore added some structure to dispatch on, which I tentatively named
MPSManifold.This is just a glorified collection of all of the spaces, but I would argue that it nicely organizes a bit more of the logic surrounding spaces away from the logic concerning the actual constructors.
The updated workflow would now be:
I like that it separates out some code logic, especially surrounding the "full-rank-ness" of MPS, and I like the syntax, and I love that we no longer have a million weird constructors that would have to be supported, but before I go in and update the docs, and do the same for the
InfiniteMPS, I would like some feedback.Does this make sense? Is it too convoluted? Do you think it is an improvement?
It would be fairly straightforward to add various utility functions to this interface as well, such as
vcat,repeat, ...