-
Notifications
You must be signed in to change notification settings - Fork 50
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
Update Noisy Circuits Documentation and Simulation #456
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #456 +/- ##
==========================================
- Coverage 82.82% 82.76% -0.06%
==========================================
Files 70 70
Lines 4651 4747 +96
==========================================
+ Hits 3852 3929 +77
- Misses 799 818 +19 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, Isaac! This is shaping up well. I am sending along a few change requests:
- tests
- removing some code repetition
- embedding the mermaid diagram differently
src/operator_traits.jl
Outdated
operatordeterminism(::Type{sMZ}) = NondeterministicOperatorTrait() | ||
operatordeterminism(::Type{sMX}) = NondeterministicOperatorTrait() | ||
operatordeterminism(::Type{sMY}) = NondeterministicOperatorTrait() | ||
operatordeterminism(::Type{sCNOT}) = DeterministicOperatorTrait() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These should not be needed. Even on the current master I get:
julia> QuantumClifford.operatordeterminism(sMY)
QuantumClifford.NondeterministicOperatorTrait()
julia> QuantumClifford.operatordeterminism(sCNOT)
QuantumClifford.DeterministicOperatorTrait()
These are already appropriately defined for the abstract supertypes, so they are inherited for sMZ or sCNOT
src/petrajectory.jl
Outdated
function applybranches(::NondeterministicOperatorTrait, state, op::sMZ; max_order=1) | ||
s = copy(state) | ||
d, anticom, res = projectZ!(s, op.qubit) | ||
if isnothing(res) | ||
tab(stabilizerview(s)).phases[anticom] = 0x0 | ||
s1 = copy(s) | ||
tab(stabilizerview(s)).phases[anticom] = 0x2 | ||
s2 = s | ||
return [(s1, continue_stat, .5, 0), (s2, continue_stat, .5, 0)] | ||
else | ||
return [(s, continue_stat, 1, 0)] end | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The addition of this guy now requires some form of a test to be added to the test runner as well.
E.g. it can be running a sHadamard
followed by an sMZ
and confirming that the result is 50/50 split between 0 and 1.
Also running an just a sMZ
and confirming that the result is 100% 0.
src/petrajectory.jl
Outdated
return [(s, continue_stat, 1, 0)] end | ||
end | ||
|
||
function applybranches(::NondeterministicOperatorTrait, state, op::sMX; max_order=1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tests
src/petrajectory.jl
Outdated
return [(s, continue_stat, 1, 0)] end | ||
end | ||
|
||
function applybranches(::NondeterministicOperatorTrait, state, op::sMY; max_order=1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tests
return [(s1, continue_stat, .5, 0), (s2, continue_stat, .5, 0)] | ||
else | ||
return [(s, continue_stat, 1, 0)] end | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is a lot of code repetition in applybranches
for sMY
and sMX
and sMZ
. There is a private function called project_cond!
(you can see it being used in projectX! projectY! projectZ!
) that should let you remove a ton of the code repetition.
Or even more simply, you can do something like op::T, ...) where {T<:Union{sMZ,sMX,sMY}}
in the type signature and then do
if T===sMZ
...
elseif T===sMX
...
elseif T===sMY
...
else
error("not reachable")
end
if size(circuit)[1] == 0 | ||
return A() | ||
DataStructures.inc!(dict, (state,continue_stat), branch_weight) | ||
return dict |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this new behavior also need a test (potentially the same test as the one for the new functionality above)
docs/src/noisycircuits_perturb.md
Outdated
@@ -42,7 +42,7 @@ circuit = [n,g1,g2,m,v] | |||
|
|||
petrajectories(initial_state, circuit) | |||
``` | |||
|
|||
[![](https://mermaid.ink/img/pako:eNq1lltvmzAUgP-K5T60k6DiFrogbS_r9raLljxUCXkwxiRWDI58WRc1_e91MVlIyzRteH4JHH_n41g6jv0AMS8JzGDeVIzf4w0SCsxv8waYIRVSZHl3BxaLFfD994cZrTVDivIGRIe1mQzR1fLDl69zEHrx6s2fs2KbVfxdVmiz8OssW4PlNcZEykMbi451RV5yxhYDbPEbFgP_2sAfheCiQ_EwGp2XIIjUTEXL7-3vqscVfaXF4gEMD-jCc64LGk7q-mo503UXkgA1JZD7uuCMYrATvEAFZVQReSy5q8_m9kNxP2QezOsPxDSRy289jZ0-jbnQBHTFAvAOBNfTIJ4k6UvuE6JMCwIsE8TpJEinryEmT7YWnCQ3aZCsjn2yZ8R2C6goY9lF1Q4PVLxRfoVqyvYZuJwRQatLTyrBtyS7CNrRV3StM95ROHDg8Y7IwVoiB2uJRq6la2wXksiFJB4nMbtonMBuwH91MNpsZ60nAOfzHe7f01JtsnD308OccZEVDOGtN_SBl8bQuTFyboydGxPnxolzY-rceOPc-Na5ceq-w__DpnG_a8Lx2wZ6sCaiRrQ0V8GH5w_kUG1ITXKYmceSVMj8FebmlvhoUKQVn-0bDDNljn4PCq7XG5hVz0e3B_WuNMfALUVrgepf0R1qFpyf3klJFRef7eWzvYM-PgGgdnFL?type=png)](https://mermaid-js.github.io/mermaid-live-editor/edit#pako:eNq1lltvmzAUgP-K5T60k6DiFrogbS_r9raLljxUCXkwxiRWDI58WRc1_e91MVlIyzRteH4JHH_n41g6jv0AMS8JzGDeVIzf4w0SCsxv8waYIRVSZHl3BxaLFfD994cZrTVDivIGRIe1mQzR1fLDl69zEHrx6s2fs2KbVfxdVmiz8OssW4PlNcZEykMbi451RV5yxhYDbPEbFgP_2sAfheCiQ_EwGp2XIIjUTEXL7-3vqscVfaXF4gEMD-jCc64LGk7q-mo503UXkgA1JZD7uuCMYrATvEAFZVQReSy5q8_m9kNxP2QezOsPxDSRy289jZ0-jbnQBHTFAvAOBNfTIJ4k6UvuE6JMCwIsE8TpJEinryEmT7YWnCQ3aZCsjn2yZ8R2C6goY9lF1Q4PVLxRfoVqyvYZuJwRQatLTyrBtyS7CNrRV3StM95ROHDg8Y7IwVoiB2uJRq6la2wXksiFJB4nMbtonMBuwH91MNpsZ60nAOfzHe7f01JtsnD308OccZEVDOGtN_SBl8bQuTFyboydGxPnxolzY-rceOPc-Na5ceq-w__DpnG_a8Lx2wZ6sCaiRrQ0V8GH5w_kUG1ITXKYmceSVMj8FebmlvhoUKQVn-0bDDNljn4PCq7XG5hVz0e3B_WuNMfALUVrgepf0R1qFpyf3klJFRef7eWzvYM-PgGgdnFL) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's embed this directly as mermaid code so that it is easier to edit in the future. You can see an example of this here:
FYI, for this to work, this folder also needs to exist: https://github.com/QuantumSavory/QuantumSavory.jl/tree/master/docs/src/assets
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, Stefan! It appears we don't need the <code></code>
HTML tags when embedding the mermaid diagrams. In fact, in QuantumSavory
, there are two ways in which mermaid diagrams are embedded:
- with HTML
<code></code>
:https://github.com/QuantumSavory/QuantumSavory.jl/blob/master/docs/src/register_interface.md?plain=1#L39 (causes error in documenter-dark mode) - without HTML
<code></code>
: https://github.com/QuantumSavory/QuantumSavory.jl/blob/8e0ba5bbadf899d6e7d029c32693af37299b6de0/docs/src/howto/firstgenrepeater/firstgenrepeater.md?plain=1#L130
There is rendering error in documenter-dark mode where <code></code>
are used: QuantumSavory/QuantumSavory.jl#174.
Since you provided the aforementioned link to<code></code>
HTML tags, I wanted to send this message to possibly help avoid documenter-dark mode errors here. Please help review this message, thank you!
Update docs for peturbative expansion simulation and add a flow chart
Add more functionality to peturbative expansion
If you want to submit an unfinished piece of work in order to get comments and discuss, please mark the pull request as a draft and ping the repository maintainer.
Please address only one topic or issue per pull request! Many small PRs are much easier to review and merge than one large PR.
Before merging, all changes and new functionality should be marked in the CHANGELOG file, but feel free to just leave your CHANGELOG notes in the PR description, to avoid merge conflicts with other requests modifying that file. The maintainer will add these CHANGELOG notes for you if you do so.
Before considering your pull request ready for review and merging make sure that all of the following are completed (please keep the clecklist as part of your PR):
If possible, keep your git history not too wild (rebase and squash commits, keep commits small and semantically separated) so that review is easier.