Open grossardt opened 3 months ago
The idea here is that each operator should be able to inform about the number of "informational bits" which it acts upon.
Since the SparseLabelOp
is generic (as you say) we have opted for a name which is generic.
To be more concrete, in the case of a FermionicOp
its register_length
equals the number of fermionic orbitals (or spin orbitals in an electronic structure picture). In a BosonicOp
the register_length
equals the number of bosonic modes.
Other cases may be more complicated, for example the VibrationalOp
differentiates the different modals within each of its vibrational modes. Its register_length
equals the sum of all modals along its modes.
Since the register_length
function has a @property
decorator, its value is accessed like an attribute (i.e. without parentheses). You will see this used around the stack in various places, but the meaning of the returned value is very much context-dependant.
Hope this clarifies things. Documentation of this could probably be improved.
(More a feature removal request, actually)
Both
second_q.hamiltonians.hamiltonian.Hamiltonian
andsecond_q.operators.SparseLabelOp
(and accordingly all their children) require a.register_length()
method. However, this method does not seem to be used anywhere at the moment? What is the point of having this method? From a logical point of view, it seems weird to associate a register length with an operator, as the size of a qubit register should only be clear after mapping?The docstrings are rather cryptic, with
SparseLabelOp.register_length()
simply saying: "Returns the register length" andHamiltonian.register_length()
the not much more informative "The size of the operator generated by thesecond_q_op
method." How does one measure the size of an operator? Especially sinceSparseLabelOp
is supposed to be rather generic and not make any assumptions about the types of string labels it holds, I am not really sure what I should expect from this method as a return value?