search

unitaryfund / pyqrack

Pure Python bindings for the pure C++11/OpenCL Qrack quantum computer simulator library
MIT License
16 stars 8 forks source link

v0.9.0: Exception handling and choice of CPU-only #12

Closed WrathfulSpatula closed 2 years ago

WrathfulSpatula commented 2 years ago

Currently, if any OpenCL device ICD is visible to the PyQrack package binaries, then CPU-only simulation cannot be selected, at all. (It is possible to force CPU-only operation by installing PyQrack from source, along with Qrack from source, installed in /usr/local with CMake and make, but...) We should give the full discretion to explicitly choose CPU-only simulation. This will constitute v0.9.0, with any further updates in the Qrack binary.

WrathfulSpatula commented 2 years ago

I think I'm going to be able to include exception handling in v0.9.0. Likely release date is tomorrow, as it goes around here.

WrathfulSpatula commented 2 years ago

So, main branch already has get_error(self) in QrackSimulator. It made more sense to me to automatically check the error code within the simulator itself, and raise a Python exception on failure, since Python can finally handle that exception. However, it's not necessarily advantageous to force exception handling, either, if no exception need be raised when get_error() is checked.

Either way, it's on user code to either check for exception, or to be forced to handle exceptions. get_error() as the preferred method is not without precedent, like in the OpenCL API itself. We might be better off simply leaving the best practice of get_error() checks up to the user, but the real problem might be we need to build real documentation at some point, as well.

WrathfulSpatula commented 2 years ago

The previous comment might sound good in the abstract, but problem is that the simulator turns out no longer to be stable after an error code is raised, basically requiring the user labor of checking the code at every method call. It is far simpler for the QrackSimulator() to automatically check and throw, as the exception can "bubble up" to higher levels of Python interpreter stack.