Update handling statevector data types in Python #290
Conversation
|
Hello. You may have forgotten to update the changelog!
|
…ning into fix_dtype_py
…ning into fix_dtype_py
| return LightningQubit(wires=1) | ||
| @pytest.fixture(scope="function", params=[np.complex64, np.complex128]) | ||
| def qubit_device_1_wire(request): | ||
| return LightningQubit(wires=1, c_dtype=request.param) |
There was a problem hiding this comment.
Instead of inserting datatype directly to a statevector, we now set the device datatypes. Test suits are updated accordingly.
chaeyeunpark
requested review from
maliasadi and
mlxd
and removed request for
maliasadi
Codecov Report
@@ Coverage Diff @@
## master #290 +/- ##
==========================================
- Coverage 99.19% 99.18% -0.02%
==========================================
Files 28 28
Lines 3105 3060 -45
==========================================
- Hits 3080 3035 -45
Misses 25 25
Continue to review full report at Codecov.
|
|
Codecov reports failure as some lines are removed (thus decreasing |
chaeyeunpark
changed the title
There was a problem hiding this comment.
Great work on this @chaeyeunpark
It'll be great to finally have complete fp32 support across the board.
| return LightningQubit(wires=1) | ||
| @pytest.fixture(scope="function", params=[np.complex64, np.complex128]) | ||
| def qubit_device_1_wire(request): | ||
| return LightningQubit(wires=1, c_dtype=request.param) |
tests/test_adjoint_jacobian.py
Outdated
|
|
||
| def test_interface_torch(self, dev): | ||
| """Test if gradients agree between the adjoint and finite-diff methods when using the | ||
| Torch interface""" | ||
| if dev.R_DTYPE == np.float32 and not lq._CPP_BINARY_AVAILABLE: | ||
| pytest.skip("Skip as default.qubit with a single precision floating point works poorly") |
There was a problem hiding this comment.
Is there a better descriptor here for what is wrong? Rather than "works poorly",maybe reduced performance, unsupported operations, etc? I don't think this is an issue, but may be useful to know the problem for future fixes.
There was a problem hiding this comment.
Sure. It is basically finite-diff with a single-precision floating-point type produces a huge error. By adjusting h, I could make it better for lightning.qubit but not for default.qubit. Proably, the gate implementations in default.qubit are not much error stable. Anyway, I will update the message.
There was a problem hiding this comment.
Okay it seems like setting h=2e-3 in finte-diff reduces errors. I will use this set-up.
Before submitting
Please complete the following checklist when submitting a PR:
All new features must include a unit test.
If you've fixed a bug or added code that should be tested, add a test to the
testsdirectory!All new functions and code must be clearly commented and documented.
If you do make documentation changes, make sure that the docs build and
render correctly by running
make docs.Ensure that the test suite passes, by running
make test.Add a new entry to the
.github/CHANGELOG.mdfile, summarizing thechange, and including a link back to the PR.
Ensure that code is properly formatted by running
make format.When all the above are checked, delete everything above the dashed
line and fill in the pull request template.
Context: With recent change in PennyLane,
default.qubitwhich is the parent class oflightning.qubit, now accepts datatypes for a statevector. This PR updateslightning.qubitdevice to utilize this new feature.