Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

virtualspace conventions can be confusing #103

Closed
lkdvos opened this issue Dec 5, 2023 · 4 comments · Fixed by #205
Closed

virtualspace conventions can be confusing #103

lkdvos opened this issue Dec 5, 2023 · 4 comments · Fixed by #205
Labels
documentation Improvements or additions to documentation question Further information is requested

Comments

@lkdvos
Copy link
Member

lkdvos commented Dec 5, 2023

Currently, the use of virtualspace across the package can be a bit confusing, and there are contradicting choices that have been made which further add to the confusion.

The current state of affairs:

  • Creating FiniteMPS objects, the constructor can take in a vector of virtual spaces which is one shorter than the length of the physical spaces, with optional kwargs for a left and right starting space. Thus, the ith element of the input vector corresponds to the virtual space to the right of site i.
  • Creating InfiniteMPS objects, there is no trivial left and right starting space, thus the vector of virtual spaces is the same length as the vector fo physical spaces. In this case, the ith element of the vector corresponds to the virtual space to the left of site i.
  • Querying the virtual space of an MPS object, we have left_virtualspace(state, i) and right_virtualspace(state, i), which return the left (right) virtual space of the bond tensor to the right of site i.
  • entanglement_spectrum yields the singular values of the bond matrix to the right of the physical site.

Clearly, there are some inconsistencies, as well as left_virtualspace and right_virtualspace being a bit misleading.

One solution might be to:

  1. Update the constructor for the InfiniteMPS to reflect that we most often refer to virtual spaces as being to the right of a physical site.
  2. Introduce a new (exported) method virtualspace, which asserts that left- and right- virtualspace to the right of a site, for given state, are equal and then returns this. This should only fail if the user updated a (finite?) MPS manually with a changed bond dimension, in which case the (unexported) internal methods left_virtualspace and right_virtualspace can be used as a more expert-user-case.
  3. Reflect everything clearly in the documentation and check if there are any more cases where this is relevant. In all cases, we adopt the convention that virtualspaces are defined to the right of a site index.
@lkdvos lkdvos added documentation Improvements or additions to documentation question Further information is requested labels Dec 5, 2023
@lkdvos
Copy link
Member Author

lkdvos commented Dec 6, 2023

EDIT: apparently, also creating an InfiniteMPS already uses the vector of virtual spaces to the right of the sites, further proving that everything is a bit confusing...

@maartenvd
Copy link
Collaborator

I think I started with virtualspace referring to the right virtualspace. However in hindsight, it is more natural to make this refer to the left virtualspace instead. If you write down a finite mps, then the first virtual space you encounter is the left one - but this would require rewriting quite a bit of code, with very little gain...

@Jutho
Copy link
Member

Jutho commented Dec 9, 2023

If you also want the left and rightmost virtual spaces, there are N+1 bonds for N sites. In that case, I would rather enumerate the bonds from 0 to N than from 1 to N+1.

Another factor is to have it consistent with how C is labeled? I assume it is also AL(n) - C(n) - AR(n+1)?

@maartenvd
Copy link
Collaborator

for C we have CL and CR, so that AL(n) - CR(n) = CL(n) - AR(n). They're just shifted copies of eachother, but maybe we should pick a convention and stick to one...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation question Further information is requested
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants