♻️ Refactor handling of gate matrices and inverses #484
Labels
c++
Anything related to C++ code
Core
Anything related to the Core library and IR
DD
Anything related to the DD package
enhancement
New feature or request
good first issue
Good for newcomers
help wanted
Extra attention is needed
refactor
Anything related to code refactoring
Milestone
After #460, all gates in MQT Core have a proper inverse now.
A natural follow-up would be to consolidate the following methods:
mqt-core/src/operations/StandardOperation.cpp
Lines 471 to 559 in 95541a6
mqt-core/include/dd/Operations.hpp
Lines 27 to 93 in 95541a6
mqt-core/include/dd/Operations.hpp
Lines 117 to 237 in 95541a6
There is lots of redundancy in the handling of the
inverse
throughout the code base.I do not have a perfect solution for resolving that in mind. It would be pretty convenient though if any operation could return its gate matrix. So essentially to refactor https://github.com/cda-tum/mqt-core/blob/main/include/dd/GateMatrixDefinitions.hpp so that the appropriate matrix can be queried from an
Operation
.To this end, it could be nice to adopt a strategy similar to Qiskit where there are individual classes for gates that all derive from
StandardOperation
(and potentiallySymbolicOperation
for parametrized gates). As an example:XGate
class that provides a method to get the single-qubitGateMatrix
, the type of the gate (already covered by StandardOperation), the inverse type, the inverse GateMatrix and potentially other useful methods.constexpr
convenience functions likeisSingleTargetGate
,isTwoTargetGate
, andisThreeOrMoreTargetGate
would probably make sense.iSWAPdg
redundant again.Originally posted by @burgholzer in #460 (review)
The text was updated successfully, but these errors were encountered: