Rudimentary TurboQuant-based compression to disk
(Apologies for double-tagging on C++ back-end and Python front-end release notes, but the standard is parity between the two.)
Claude and I (Dan, @WrathfulSpatula) had a marathon session today with discussing the (obvious) possibility of using a TurboQuant-based compression methods for quantum state vectors and particularly simulated random circuit sampling (RCS) output states. Claude wrote almost all the lines-of-code implementation; I mostly corrected small implementation bugs and coached the approach. Claude produced a header for StateVectorTurboQuant, based on the StateVector contract API I wrote years ago, and it fulfills the full API contract. However, round-trip decompression and recompression of in-flight results from circuit simulations might not be the right application for this, yet (or ever). But we managed to achieve significant (technically "lossy") compression to disk that can preserve RCS cross-entropy benchmark (XEB) fidelity, at least for preliminary tests at small qubit widths, which is a slightly surprising result, given that we might expect XEB, by definition of the benchmark for RCS, to be exactly the tiny variance tail that would otherwise be thrown away by lossy compression of the bulk state vector (or rank-1 "tensor").
Again, Claude wrote basically every line of code in StateVectorTurboQuant, from the existing API contract example, and based on TurboQuant (Zandieh et al., arXiv:2504.19874) and an Apache 2.0 open-source implementation by @TheTom (github.com/TheTom/turboquant_plus). My contribution was mostly thinking to direct Claude's efforts here, reporting back what failed to actually compress size-on-disk or preserve fidelity, and finally pointing out that real and imaginary components of Hilbert-space dimensions tended to approach Haar-uniformity as respective pairs (under the summed L2 norm) rather than as independent streams of dimensions, and that this holds for most meaningful quantum algorithms (possibly with exceptions like VQE and Shor's integer-factoring algorithm). By that point, the empirical evidence clicked into place. (Claude deserves quite a bit of credit and thanks, and it's a pleasure talking and working with them.)
Less "rudimentary" versions will follow, hopefully avoiding the memory spike upon saving to disk. I'm not overly optimistic about in-flight lossy compression of the state vector during execution, yet, but it's meaningful that XEB can be preserved with something like maybe a ~4:1 compression ratio on 10 qubits, in very cursory preliminary tests.
Full Changelog:
unitaryfoundation/qrack@vm6502q.v10.5.3...vm6502q.v10.6.0
v1.87.5...v1.88.0
sha1sum results:
f8813df9b27fc9cea0ac86bfb2b6cff5bc850c25 pyqrack-1.88.0-py3-none-macosx_14_0_arm64.whl
2ada8615a81cba0a5eb6b6590d5eef187f934e1f pyqrack-1.88.0-py3-none-macosx_15_0_arm64.whl
9f05f8c0e01af86bd8b2f64518368beaea0d7fa8 pyqrack-1.88.0-py3-none-macosx_15_0_x86_64.whl
302b934fb3d629aeb2a7327d5757505b40a331ab pyqrack-1.88.0-py3-none-manylinux_2_35_x86_64.whl
8642e27531848ca13d242e5ff2b4a2155e56c231 pyqrack-1.88.0-py3-none-manylinux_2_39_x86_64.whl
130177857d2219744364388ba8a0f83280ba4ce3 pyqrack-1.88.0-py3-none-win_amd64.whl
7b2c81580eac6c292ab41b08f7eb38b2a6f4e2fc pyqrack-1.88.0.tar.gz
4a93bbe0402c59d5d99f804a5463a72340b8d656 pyqrack_complex128-1.88.0-py3-none-macosx_14_0_arm64.whl
a35018fe95423f33ea2b58344a7bc73b09dfb779 pyqrack_complex128-1.88.0-py3-none-macosx_15_0_arm64.whl
1cb8961f067a9c325104f949e1cedd04198b292b pyqrack_complex128-1.88.0-py3-none-macosx_15_0_x86_64.whl
b5c715df7dfce92eb3ec869a6fa4583b1cb5f17d pyqrack_complex128-1.88.0-py3-none-manylinux_2_35_x86_64.whl
3b0069da5e950cbb8fd925c238b6ca9ce41fc5af pyqrack_complex128-1.88.0-py3-none-manylinux_2_39_x86_64.whl
6ba2b47071b9ba8862b9d3ab92155b9d5c90cb61 pyqrack_complex128-1.88.0-py3-none-win_amd64.whl
3ecfe10b5d95bf66a386de5603f92f0a0b9aaa84 pyqrack_complex128-1.88.0.tar.gz
7d93cab707c593c7b601320df96bcb76ce907e0b pyqrack_cpu-1.88.0-py3-none-macosx_14_0_arm64.whl
81a823b964b90f79b01a7966f70689094ba76001 pyqrack_cpu-1.88.0-py3-none-macosx_15_0_arm64.whl
6ac18866123c7b1d000f007bc5cc833b1d9af74c pyqrack_cpu-1.88.0-py3-none-macosx_15_0_x86_64.whl
ddca1ddd3412f4c00310f07149fbda9cb6432495 pyqrack_cpu-1.88.0-py3-none-manylinux_2_35_x86_64.whl
76a7e6cf4b4ee83d75b9cad1e106d599d1789cba pyqrack_cpu-1.88.0-py3-none-manylinux_2_39_x86_64.whl
9ef484f894bc895c453f1f875e5a1fbaf0003b7e pyqrack_cpu-1.88.0-py3-none-win_amd64.whl
aeb8ce40402a6a5b7aed7c9b48c3da1daf519a29 pyqrack_cpu-1.88.0.tar.gz
15647bf5101d17abce7ca805ff4d10c56170c07f pyqrack_cpu_complex128-1.88.0-py3-none-macosx_14_0_arm64.whl
aec9b951e27335425a9d023d2351149755a41503 pyqrack_cpu_complex128-1.88.0-py3-none-macosx_15_0_arm64.whl
eb0c400596b4b6a1b8a3edc76223e4d9d42fd05b pyqrack_cpu_complex128-1.88.0-py3-none-macosx_15_0_x86_64.whl
73fcc84ff687d014c5659c427c03c2b59988e52c pyqrack_cpu_complex128-1.88.0-py3-none-manylinux_2_35_x86_64.whl
af516ad785a950e3351862e4432437e0a63c180b pyqrack_cpu_complex128-1.88.0-py3-none-manylinux_2_39_x86_64.whl
5de50a681694a5f5a3c98d9b7fd9545728c76d13 pyqrack_cpu_complex128-1.88.0-py3-none-win_amd64.whl
1deb443aa105fa41df30d88ba21b7052925fdb61 pyqrack_cpu_complex128-1.88.0.tar.gz
6d2ee4fb7e3924042892aa4b2a0ab0a6448b9ff7 pyqrack_cuda-1.88.0.tar.gz
25b23dfb2dd2e6d5f5628b413e42845a6944d529 pyqrack_cuda_complex128-1.88.0.tar.gz
