-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test coverage for slow evotype classes #505
Comments
OK I can confirm the second error message is a densitymx_slow evotype bug. The bug has to do with the case where a circuit is implicitly using a Basically the difference is between the Cython directly computing effect reps:
vs the Python computing for the general POVM effect first. pyGSTi/pygsti/forwardsims/mapforwardsim_calc_generic.py Lines 45 to 50 in 916877c
I'll use test_simulate from test/unit/objects/test_circuit.py to illustrate the issue. pyGSTi/test/unit/objects/test_circuit.py Lines 614 to 627 in 916877c
This test uses a circuit defined on two qubits, but the model is defined on 4 qubits, so this is an implicit marginalized POVM. The test constructs a LocalNoiseModel, so this is the relevant POVM lookup function: pyGSTi/pygsti/models/localnoisemodel.py Lines 495 to 530 in 916877c
Both will fail the layerlbl in povm_blks check, but the else assumes that layerlbl is an effect label (e.g. "Mdefault_00" ). This is true in the Cython (evotype "densitymx") case, but not in the Python (evotype "densitymx_slow") case. In fact, we are failing at the povmreps construction line just before the effect labels would be passed in.
Two possible solutions:
Solution 1 has the advantage that it is model/layer rule independent, but I kind of like Solution 2 more. I personally prefer not having try/excepts unless there really is no reasonable alternative. We will just have to make sure that every layer rule handles both the POVM and effect label cases. Thoughts? |
As part of PR #452 we noticed that several "slow" evotype objects had an implementation for
__reduce__
that was commented out. Some of these commented out definitions indicated a need to be fixed. That raised the question of if the existing slow evotype code is broken in some way. To start the discussion on this point I ran our unit tests with code coverage enabled. Zooming in on results for evotypes, I get the followingNote: I generated this report by running
inside the test directory.
Tests results when
Evotype.default_evotype = "densitymx_slow"
The default evotype is densitymx as long as the cython extensions correctly compiled. Since we're trying to understand possible bugs in the slow evotypes I re-ran with densitymx_slow as the default evotype. This resulted in four failed unit tests.
Here's a comparison of coverage when using the densitymx_slow by default (top window) vs the plain densitymx evotype (bottom window):
Click here for details on test failures
The text was updated successfully, but these errors were encountered: