Open vincentelfving opened 3 years ago
So, a DOCIHamiltonian has a representation in fermion form (where it has twice as many spin orbitals) and one in qubit form (which we have correct). It was my intention for get_sparse_operator to provide the first, not the second, and with this specified I wouldn't expect the two representations to have the same expectation value on the same state. But, there's clearly a bug here - I would expect 'print(expectation(sp1, state).real)' to raise an error here as sp1 should be a 2^8x2^8 matrix, not 2^4x2^4. I'll check it out as soon as I can.
DOCIHamiltonian
subclassesPolynomialTensor
. That means, if a user appliesget_sparse_operator
to an instantiation of aDOCIHamiltonian
, it will 'work' and automatically assume that it is aFermionOperator
according to this check . (The reason is (I guess) that so far all such representations (QuadraticHamiltonian
,InteractionOperator
) which derive fromPolynomialTensor
were in the Fermionic context, not hard-core bosons.)Currently, the workaround is to just not give a
DOCIHamiltonian
directly, but pass its property,DOCIHamiltonian.qubit_operator
to theget_sparse_operator
function and it behaves correctly. However, such unexpected behaviour may lead to hidden bugs because no error is raised and it returns a matrix with the right dimensions.Suggested fix: add DOCIHamiltonian to the checks like this, which should occur before the
PolynomialTensor
check:(I have not checked if similar behaviour happens elsewhere apart from in
get_sparse_operator
)Example snippet:
0.25819950204147385 -1.0570826874100623