Pyqrack

Latest version: v1.27.8

Safety actively analyzes 628903 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 39 of 45

0.8.5

In the underlying Qrack binary, random number generation ("RNG") code continues to be overhauled. Stabilizer special case implementations have been added. The remaining calls to retrieve OpenCL device information have been fully centralized, and an **intentional** memory leak due to the use of a singleton for OpenCL context management has been replaced with a singleton pattern that fixes the leak, (by allocating the singleton instance on stack).

0.8.4

This updated Qrack binary gives better performance, for optimal default "layer stack" options! (This primarily affects use cases where no default layer stack options are changed in the Qrack simulator constructor.)

0.8.3

Random number generation handling has been improved in the Qrack binaries:
- Stabilizer uses 1/32 the amount of random numbers on the same task.
- Linux systems that implement a system call for `/dev/urandom` now use that system call install of the RDRAND x86_64 on-chip random number generation instructions, where `/dev/urandom` appears to work faster for the purpose, with no appreciable or easily detectable drawbacks.

A wheel has also been produced for **ARM64 Linux**, specifically on a Raspberry Pi 4. The tag is not yet standardized for the platform, hence PyPi will not accept it, but `pyqrack-0.8.3-py3-none-linux_aarch64.whl` is available in the wheels ZIP file attached to this release, (assuming ARM64 standardization is likely to reflect ARMv7 standardization, as `pyqrack-0.8.3-py3-none-linux_armv7l.whl`).

0.8.2

In this release, the Qrack binaries use significantly fewer threads, while performance is typically _not_ reduced, as a result.

0.8.1

The combination of "POCO" and "RAII" semantics seem to result in a big speed increase!

0.8.0

This release introduces the `m_all()` method for `QrackSimulator` instances. `m_all()` collapses and returns a measurement result on all qubits in the simulator instance, low-to-high bit order as first-to-last allocation order. `m_all()` gives excellent execution speed for single samples, compared to `measure_shots()`.

If you are allocating more than 32 qubits, for special cases, `m_all()` will only report the value of the first 32, but the operation will collapse all qubits in the simulator via Z basis measurement, reliably. Following up the operation with additional measurements as necessary, in that case, will (almost) always preserve the overall performance boost, after the qubit register is collapsed.

Page 39 of 45

Links

Releases

Has known vulnerabilities

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.