Pyqrack

I was hasty in the release notes, earlier today: _much_ has changed on my particular hardware, including Intel firmware. While I was frustrated that something appeared to change, out from under us, it's not necessarily due to NVIDIA drivers (though that might contribute), and, conceivably, it _might_ have _everything_ to do with speculative code execution.

In any case, typical use-case performance seems to benefit from also disabling "hybrid stabilizer" mode in PyQrack by default. Regarding this release and v1.32.25 earlier today, _no functionality has been removed._ It is possible to recover the original behavior (which might be better suited for your system, depending) with `isStabilizerHybrid=True` and `isCpuGpuHybrid=True` passed to the `QrackSimulator` constructor. However, on an RTX 3080 laptop, performance for typical workloads seems to benefit _immensely_ from turning both options off (by this point in history, whereas this might not have been the case in past years).

We will update the documentation and API reference to indicate the new default constructor options, but the new defaults might be more intuitive for most users: stabilizer (even "hybrid," universal) is a special-case algorithm, and `"hybrid CPU/GPU" is something to experiment with on your local system, whereas GPU could be expected to be used by default if you have a GPU.

**Full Changelog**: https://github.com/unitaryfund/pyqrack/compare/v1.32.35...v1.32.26

sha1sum results:
8c83ec6953f93c7eb59282f476273a139ed1561e pyqrack-1.32.26-py3-none-macosx_13_0_x86_64.whl
7263725151813f1c604cdbc015bda2189c730df7 pyqrack-1.32.26-py3-none-macosx_14_0_arm64.whl
a934b0bc2ddbdf36e086edeedfb4344717b9b74b pyqrack-1.32.26-py3-none-macosx_15_0_arm64.whl
9c4c03dbd58f1c92f7921e1b5fc5a8b2d7c12428 pyqrack-1.32.26-py3-none-manylinux_2_31_x86_64.whl
8c9b27ae1b6f725049582a7c75bc9352ff1153e9 pyqrack-1.32.26-py3-none-manylinux_2_35_x86_64.whl
f1815a2e67962c15226c7e1cc41473c8961dd773 pyqrack-1.32.26-py3-none-manylinux_2_39_x86_64.whl
b1accbe2e49358807188fb269315c4ad217e97cf pyqrack-1.32.26-py3-none-win_amd64.whl
bf019ed9cf4c31f7470854e9d1360bc2e2ee2309 pyqrack-1.32.26.tar.gz
8a8a34412f9c6d15aa621e975e1f3c5e8f061c52 pyqrack_cpu-1.32.26-py3-none-macosx_13_0_x86_64.whl
20d0ab86764e38c4b863ba2afb7acdaa428af6b7 pyqrack_cpu-1.32.26-py3-none-manylinux_2_31_x86_64.whl
b63c1a2c099484e729a04f5492561453183b6576 pyqrack_cpu-1.32.26-py3-none-manylinux_2_35_x86_64.whl
f30aa21c33ab9a602484ff5cecc9c673cd651d37 pyqrack_cpu-1.32.26-py3-none-manylinux_2_39_x86_64.whl
37d0054acd7589f605ea7b565daf2738c84d9b10 pyqrack_cpu-1.32.26-py3-none-win_amd64.whl
e3c214df31962492215b71db7204a94c01f34be2 pyqrack_cpu-1.32.26.tar.gz

For years, it was always the case that low qubit width run on GPU-based simulation methods "plateaued" at a certain higher value than CPU-based methods at the same width, because full GPU parallelism couldn't be engaged for small numbers of work items. To alleviate this condition, years ago, Qrack implemented `QHybrid`, to intelligently switch between GPU-based and CPU-based methods.

Apparently, NVIDIA has fixed this behavior at driver level. (Dan is not going to lie: he's a little "miffed" that no one pointed this out to us specifically, when we've had rapport with the CUDA-Q team in the past, and the first to smooth over this imperfection at software rather than driver level _**was Qrack**._) Hence, `QHybrid` will remain available for legacy drivers and other vendors who can benefit from it, but this optimizing "layer" will be disabled by default.

**Full Changelog**:
https://github.com/unitaryfund/qrack/compare/vm6502q.v9.12.28...vm6502q.v9.12.32
https://github.com/unitaryfund/pyqrack/compare/v1.32.21...v1.32.35

sha1sum results:
431fd6cadb3277cf768913ef45103ea5eabc563e pyqrack-1.32.25-py3-none-macosx_13_0_x86_64.whl
08033a9f910ac7f1a21250deb720c5949db2ca6e pyqrack-1.32.25-py3-none-macosx_14_0_arm64.whl
3363a9f8faee57fda779b4d98c7419482bcea4cd pyqrack-1.32.25-py3-none-macosx_15_0_arm64.whl
202ddfdb2a152b812cbc3c72c4e105b4e1d95797 pyqrack-1.32.25-py3-none-manylinux_2_31_x86_64.whl
dea85dd4113dafb1ad9b91720dd7971c00754553 pyqrack-1.32.25-py3-none-manylinux_2_35_x86_64.whl
11f40c87e185850419732536da89fa680f0ce531 pyqrack-1.32.25-py3-none-manylinux_2_39_x86_64.whl
2c7c868f0cff0db073250b10f575950b536fed7f pyqrack-1.32.25-py3-none-win_amd64.whl
9d993f56d4e822c0da3e2ba7a6e42d3855658cc2 pyqrack-1.32.25.tar.gz
9733fcf30d331e53e8d53dc6f24ef658541a8957 pyqrack_cpu-1.32.25-py3-none-macosx_13_0_x86_64.whl
3306198fa7949bd9fff2d9f2a8af832c52ff29a2 pyqrack_cpu-1.32.25-py3-none-manylinux_2_31_x86_64.whl
7a3abc7e5a9c17cfadb741769381e2d82c933fd5 pyqrack_cpu-1.32.25-py3-none-manylinux_2_35_x86_64.whl
a982b99e66e3cab340ea194fac9f119abea3d608 pyqrack_cpu-1.32.25-py3-none-manylinux_2_39_x86_64.whl
d283f8f06fec5e11af37717768d4a3de910b06f2 pyqrack_cpu-1.32.25-py3-none-win_amd64.whl
40f4441692049c2e2c66d77e0be82e1d4f24ce60 pyqrack_cpu-1.32.25.tar.gz

In preparation for experiments in compilation, `QrackCircuit` has been slightly refactored: single-qubit gates are now allowed to combine with any multi-qubit gate that would otherwise block commutation (which should almost never incur any additional simulation overhead penalty for running the optimized circuit with Qrack), and checks for identity equivalence have been made fully exhaustive.

**Full Changelog**:
https://github.com/unitaryfund/qrack/compare/vm6502q.v9.12.27...vm6502q.v9.12.28
https://github.com/unitaryfund/pyqrack/compare/v1.32.20...v1.32.21

sha1sum results:
bf500afb9307d7201098445c850812f0cb4fd7cd pyqrack-1.32.21-py3-none-macosx_12_0_x86_64.whl
1f61117e69a1f72563f23a64c7a23d04c5cc8c57 pyqrack-1.32.21-py3-none-macosx_13_0_x86_64.whl
fabdbcb29948ec55fcc90e5ce1d7a57c42a01e22 pyqrack-1.32.21-py3-none-macosx_14_0_arm64.whl
960b3f3332ff2f9ca77af8b90b6710fac370711c pyqrack-1.32.21-py3-none-macosx_15_0_arm64.whl
5b21c4c2631a56ba866b8ef486406d8ecce4cf48 pyqrack-1.32.21-py3-none-manylinux_2_31_x86_64.whl
708cc60c0e761f7b9eef6927cef3c2c4d4ff8e9b pyqrack-1.32.21-py3-none-manylinux_2_35_x86_64.whl
f31cea9bf7632bcead80f42ba15eab13744c4c96 pyqrack-1.32.21-py3-none-manylinux_2_39_x86_64.whl
eb78d7b44138e7778e3f3b233813fe45f6de3dc3 pyqrack-1.32.21-py3-none-win_amd64.whl
147b26a56fd6112d0b4fe7cfb72d96ffcb9a95a6 pyqrack-1.32.21.tar.gz
5c4a15049cf5301cb24dcf12c56b76318ceb176e pyqrack_cpu-1.32.21-py3-none-macosx_12_0_x86_64.whl
6ebf282cf7bed211fd56cddf02526177cd5595a7 pyqrack_cpu-1.32.21-py3-none-macosx_13_0_x86_64.whl
dc97d2419bec1caa07595961a3b7d5a266b4fc77 pyqrack_cpu-1.32.21-py3-none-manylinux_2_31_x86_64.whl
c02aaa6523551b9795c09660cc1fd7dc390f1c48 pyqrack_cpu-1.32.21-py3-none-manylinux_2_35_x86_64.whl
70f23a685ef49914f90d0736b10b674a44885fa3 pyqrack_cpu-1.32.21-py3-none-manylinux_2_39_x86_64.whl
aac0f06a5ac53bbbbdf6d34e1ddef7cdf8e92e6e pyqrack_cpu-1.32.21-py3-none-win_amd64.whl
cec8bfd17762c834649c7354166b409c1bf7794a pyqrack_cpu-1.32.21.tar.gz

QrackCircuit` (C++) `operator osstream>>` suffered from a bug where `bitLenInt` was not correctly cast to `size_t` before writing out to stream. This creates unprintable characters that could have easily crashed the output process. The problem was not recognized sooner because build settings for releases _used to_ entail that the `bitLenInt` happened to be printable as an integer.

**Full Changelog**:
https://github.com/unitaryfund/qrack/compare/vm6502q.v9.12.23...vm6502q.v9.12.27
https://github.com/unitaryfund/pyqrack/compare/v1.32.19...v1.32.20

sha1sum results:
0d5b96ee5354602b9903dbd4a22102c7fa2af5c1 pyqrack-1.32.20-py3-none-macosx_12_0_x86_64.whl
7d5e9d8081855b525bc184de22efcaf1dd56a686 pyqrack-1.32.20-py3-none-macosx_13_0_x86_64.whl
9e36251b09dbac6f94028e917cde45965010d835 pyqrack-1.32.20-py3-none-macosx_14_0_arm64.whl
57425b99f8f075174b6fefa4d96fccd0620155b2 pyqrack-1.32.20-py3-none-macosx_15_0_arm64.whl
f2449e8219b1b831c6894b65ba4c682ae49c6fe4 pyqrack-1.32.20-py3-none-manylinux_2_31_x86_64.whl
61bcc7f6d63633b106148cc57e94aabb8a896f9a pyqrack-1.32.20-py3-none-manylinux_2_35_x86_64.whl
0f8365979dafd6dbc27ec96611238ae9f82b7b59 pyqrack-1.32.20-py3-none-manylinux_2_39_x86_64.whl
5ddd3c28a494180212e54c81e16bfbc29ff27b8e pyqrack-1.32.20-py3-none-win_amd64.whl
3d4ac6918200a842676a03ca2e637d6f8749ab8d pyqrack-1.32.20.tar.gz
fcfc475860ed9c052643f7f0a36ab0fe4bb191b9 pyqrack_cpu-1.32.20-py3-none-macosx_12_0_x86_64.whl
7978fa3ea7630becf5cf5adc5342498e63a92ca8 pyqrack_cpu-1.32.20-py3-none-macosx_13_0_x86_64.whl
226e840538d2559006555fc807c1dddf71368736 pyqrack_cpu-1.32.20-py3-none-manylinux_2_31_x86_64.whl
70e8ebc6157daa59e551eb2eddc7435c2fa51c98 pyqrack_cpu-1.32.20-py3-none-manylinux_2_35_x86_64.whl
8b73827881a8ee22cee46b390e27edeac895c712 pyqrack_cpu-1.32.20-py3-none-manylinux_2_39_x86_64.whl
fe16fa1441ce94b82367bfce77e9dd5cea7897d5 pyqrack_cpu-1.32.20-py3-none-win_amd64.whl
f471e29752fa2b88205022e32a6b56d72ad50a11 pyqrack_cpu-1.32.20.tar.gz

This release adds the option to disable the limiter exception on low `QUnit` fidelity estimate, by setting environment variable `QRACK_DISABLE_QUNIT_FIDELITY_GUARD` to any truthy value.

When `QUnit` encounters a situation where acting a coupler gate would require exceeding user-specified maximum system memory resources, it will automatically resort to replacing this gate with a "classical shadow" that will not require additional allocation. In the process, `QUnit` will decrease its internal first-principles unitary fidelity estimation under assumption that the classical shadow replacement effect is worst-case. If the fidelity estimate drops below floating-point rounding epsilon, `QUnit` will automatically `throw` to exit simulation early. However, particularly in cases of "anti-concentration," such as with universal random circuit sampling, this first-principles worst-case fidelity estimate might be very overly severe. In these cases, the worst-case fidelity estimate cannot necessarily be trusted not to be (potentially very) overly pessimistic, but the throw condition on low fidelity estimate can be disabled by assigning any value to environment variable `QRACK_DISABLE_QUNIT_FIDELITY_GUARD`.

**Full Changelog**:
https://github.com/unitaryfund/qrack/compare/vm6502qv9.12.23...vm6502q.v9.12.23
https://github.com/unitaryfund/pyqrack/compare/v1.32.18...v1.32.19

sha1sum results:
e65036260838ac596a5b0518a79b0f06926b28a3 pyqrack-1.32.19-py3-none-macosx_12_0_x86_64.whl
f27a444f7376bb892724e212f3b1188aae2b3e50 pyqrack-1.32.19-py3-none-macosx_13_0_x86_64.whl
fa4926eac7709a18a9b669a98486c16398b1124f pyqrack-1.32.19-py3-none-macosx_14_0_arm64.whl
f69620de15afe3b6606c0287ce638d1f4c49e7d0 pyqrack-1.32.19-py3-none-macosx_15_0_arm64.whl
2cf24f10930d23e7e0dfc6ede852dd82a495fe63 pyqrack-1.32.19-py3-none-manylinux_2_31_x86_64.whl
3ebb349646fcf89cd89f12426689e74821ee4720 pyqrack-1.32.19-py3-none-manylinux_2_35_x86_64.whl
2f47136eb10bbf770e2ad3fb375a35bd10e6d8d3 pyqrack-1.32.19-py3-none-manylinux_2_39_x86_64.whl
3132be3673996d616ee6e1098d65b0cbc2fe93ee pyqrack-1.32.19-py3-none-win_amd64.whl
27d6fe47ad4d2c8aa7500b6599fea0a20b1f2b40 pyqrack-1.32.19.tar.gz
fdfbcc678d0db2264fa819e6a1e1ab0d9b5c358b pyqrack_cpu-1.32.19-py3-none-macosx_12_0_x86_64.whl
50d4136af8ff288777c431e9b557c6844441730a pyqrack_cpu-1.32.19-py3-none-macosx_13_0_x86_64.whl
5bfd5565bf81e95dd0a55e1fe08d62ff4fd3ab02 pyqrack_cpu-1.32.19-py3-none-manylinux_2_31_x86_64.whl
3029d1e9089fc361bbd06963037111e354a4288b pyqrack_cpu-1.32.19-py3-none-manylinux_2_35_x86_64.whl
20ffa26950ae99218531908f0244fdc37b7b7bfa pyqrack_cpu-1.32.19-py3-none-manylinux_2_39_x86_64.whl
80666c6238801f9d9e5f02228dceaddcbb81ceac pyqrack_cpu-1.32.19-py3-none-win_amd64.whl
8a8312abe711fe6402aa3f3fd6ab6045cbd79421 pyqrack_cpu-1.32.19.tar.gz

Qrack errata commit [bc1d5d89](https://github.com/unitaryfund/qrack/commit/bc1d5d890a0537bafde7f9f853640487a5e4b69f) 🪨✌️💜

**[Errata is not necessary; v1.32.17 is correct.]**