v0.14
This minor release adds support for diagonal matrices, a validation improvement, and a patch to an esoteric bug in ApplyCircuitDerivs[]
.
New features
-
Gates
U
,UNonNorm
andMatr
, which previously accepted dense matrices (specified element-wise), now addtionally accept diagonal matrices specified as flat lists. Such diagonal gates have bespoke backend QuEST simulation functions (invoked by functions likeApplyCircuit[]
), and bespoke/optimised Mathematica handling (invoked by functions likeCalcCircuitMatrix[]
andSimplifyCircuit[]
).For example, operators specified as
U_0[ {{a,0}, {0, b}} ]
and
U_0[ {a,b} ]
are equivalent, though the latter is (approximately) quadratically faster (in terms of its dimension) to simulate.
Changes
- derivative functions
ApplyCircuitDerivs[]
,CalcMetricTensor[]
andCalcExpecPauliStringDerivs[]
now explicitly check whether the given density matrix is Hermitian (otherwise throwing an error), since this is a pre-condition to their correct function.
Bug fixes
-
patched an esoteric
ApplyCircuitDerivs
bug when differentiating with respect to a parameter in aMatr[]
operator upon a density matrix.
Precisely; the existingMatr
gate modifies density matricesrho
under
rho -> Matr rho
Previously,
ApplyCircuitDerivs[]
would compute the derivative ofMatr
as
D( Matr ||rho>> ) = conj(Matr) (x) D(Matr) ||rho>> + adj
where||rho>>
notates the equivalent vector under the Choi isomorphism.This formulation is erroneous, and treats
Matr
like a unitary gate operated as
rho -> U rho dagger(U)
Instead, the true derivative of Matr is simply;
D(Matr) ||rho>>
This bug was extremely esoteric and was likely not encountered by users, since such state derivatives are typically used by variational algorithms leveraging unitary ansatzse. It also did not affect similar functions like
CalcExpecPauliStringDerivs[]
andCalcMetricTensor[]
, which already forbid non-trace-preserving operators likeMatr
.