Closed jlbosse closed 1 year ago
Patch coverage: 100.00
% and project coverage change: +0.04
:tada:
Comparison is base (
dc9d152
) 88.24% compared to head (deb661f
) 88.28%.
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
Currently qubit_type() is defined only for YaoArrayRegister and DensityMatrix. But its definition is sufficiently general, that it could be moved into YaoAPI. Shall I do that?
In a separate PR, yes.
More aesthetic: Currently a generic density matrix is referred to as ρ, rho, r or dm in the different files of the code (and also has different names in different docstrings). Should I go ahead and homogenize the naming there, and if yes to which of the four options?
Yes, they should use the same variable name, but this is kinda written by different people at different times, so we haven't been careful. And since you are doing it, you have the right to pick your favorite except r
(it's too short as a general convention)
But please also do this in a separate PR. I think this PR is good on its own already.
qubit_type() returns a string for printing. It is not an essential API that people will be interested in implementing it. We have to keep YaoAPI easy to understand and easy to extend, so any nonessential API should not go to YaoAPI.
I added tests and docstrings to #408 .
Before this gets merged, two more questions:
qubit_type()
is defined only forYaoArrayRegister
andDensityMatrix
. But its definition is sufficiently general, that it could be moved intoYaoAPI
. Shall I do that?ρ
,rho
,r
ordm
in the different files of the code (and also has different names in different docstrings). Should I go ahead and homogenize the naming there, and if yes to which of the four options?