MPSKit.jl icon indicating copy to clipboard operation
MPSKit.jl copied to clipboard

`virtualspace` conventions can be confusing

Open lkdvos opened this issue 2 years ago • 4 comments

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 avatar Dec 05 '23 10:12 lkdvos

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...

lkdvos avatar Dec 06 '23 16:12 lkdvos

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...

maartenvd avatar Dec 07 '23 09:12 maartenvd

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)?

Jutho avatar Dec 09 '23 14:12 Jutho

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...

maartenvd avatar Dec 17 '23 12:12 maartenvd