WrathfulSpatula
commented
1 month ago This PR should correctly build a wheel with Catalyst support included
Would you mind expanding on what is required to support catalyst?
@natestemen The lines of code to wrap a back end for Catalyst are relatively minimal, though there's at least a *.cpp (C++) body file, linked statically with Qrack on the build machine, commonly built by a CMake configuration that just links and installs the simple executable.
The C++ interface is found by PennyLane and its users via a method in the Python back end class for the same "device" (which is a software simulator, in this case). Basically, Catalyst can swap in the C++ back end in for the Python back end, with the point being to improve performance (though this explanation is likely a gross simplification of what's going on and what's intended).
Besides the C++ back end, and the Python back end, there are respective device capability schema manifests, for Python and C++, which must basically be at logical parity for capability. In general, if a capability is declared on either side, Python or C++, it must be declared and implemented on both sides.
TL;DNR: Python and C++ back ends, with Catalyst and PennyLane, are device wrappers with total parity between capability manifests, such that the two back ends are perfectly interchangeable for the interface each supports. (The point of this implementation exercise is to let Catalyst improve your performance in the context of PennyLane or more generally.)
This PR should correctly build a wheel with Catalyst support included (with help from
scikit-build). All supported API features should be seen as at parity between the Python and C++ back ends, according to Catalyst.Still to do: we need tests, we need to debug, and we need to complete the implementation of the supported observables in the manifest.