Pyqrack

v0.7.0 adds the option to disable many of Qrack's optimization layers, in the system-specific optimal layer stack, (which is bimodal, depending on the presence/absence of OpenCL devices). For many specific circuits of interest, significant additional performance can be gained by disabling one or more Qrack layer stacks, if one knows the characteristics of their workload, as regards the attempted optimizations in Qrack.

(However, the default case, with _all_ optimizations layers on, is designed for best general performance based upon developer experimentation with realistic and/or high-entanglement universal circuits. It is expected that users will most commonly best benefit from leaving all optimization layers on by default, and not considering v0.7.0 options at all, without a reason.)

This release only adds support for ARM64 Linux systems. No changes to the binary source implementation or API have been made since v0.5.3.

I'm testing on a Raspberry Pi 4 with beta version 64-bit operating system, and, despite having a rather long list of platform tags for wheels that the system _should_ be compatible with, `pip` on this system only seems to accept `none-any` wheels. This doesn't prevent us from offering a `none-any` wheel that is compatible with 64-bit Raspberry Pi OS, but it does force users to use the non-specific `none-any` wheel, which includes _all_ platform binaries we support, significantly increasing the size of download and installation for the package. (The difference is _significant_, as a percentage of package size with only ARM64 binary, but the entire `none-any` wheel file is still only ~8 MB.)

Note also that the ARM64 binary here is theoretically OpenCL-ready, without modification, for systems with one or more ICDs, as are all binaries in PyQrack.

This fixes a PhaseParity edge case.

See https://github.com/vm6502q/qrack/issues/888. (Apologies again for the rapid-fire release updates. Note that if your circuit didn't raise exception with v0.5.2, you weren't affected by the PhaseParity edge case I'm struggling with, here.)

There was a bugged edge case in `QPager::PhaseParity()`, when the qubit `mask` contained _only_ "global qubits." This is fixed by v0.5.2.

PyZX includes a "PhaseParity" gate within its internal set of gates. This gate can be implemented quite efficiently, over any qubit width, at the simulator level. The Qrack binaries have been updated to efficiently implement this gate, and the native implementation can be called directly via a `QrackSimulator` instance.

This debugs PyZX `Circuit` graph support. (With this work out of the experimental phase, I expect v0.5.0 to be the first version to truly support PyZX `Circuit` graphs.)