Repository navigation
Fix --loopsum for amplitudes with an imaginary part (#22) - #65
Merged
Merged
Conversation
A loop-summarization variable v is encoded as vR + i·vI, so vI must be bound to the real number Im(x). eval_symbol bound it to FiveTuple::imag(), which is i·Im(x), so every summarized iteration ran on Re(x) - Im(x) instead of x. Rotate the value a quarter turn clockwise (multiply by -i) to get Im(x). Add a unit test that runs four loops both unrolled and summarized and requires the same printed states: the issue's example, (T·H)^3 on |0>, S·S on |1>, and a two-qubit loop with Y, H, CZ and T†. All four fail without the fix. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013gtFQRPe1eSSpmA7EJ2KNY
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #22.
The bug
With
--loopsum, every amplitude is replaced by a variablevencoded asvR + i·vI. After the fix point,eval_symbolputs the real amplitudes back in. It boundvItoFiveTuple::imag(), which isi·Im(x)and not the real numberIm(x). The term's coefficient already carries thei, so it contributedi·i·Im(x) = −Im(x), and every summarized iteration ran onRe(x) − Im(x)instead ofx. Any loop whose iterations see a complex amplitude gave wrong states. These come from a complex precondition or from gates likes,t,yorsdgin the body. The error changedververdicts in both directions.The fix
src/loop_summarization.cc: bindvItoimag()rotated a quarter turn clockwise, which multiplies it by −i and givesIm(x).clockwise()is part of theis_complexconcept, so this doesn't depend on theFiveTuplerepresentation.I left
FiveTuple::imag()alone. The HSLimag(...)function also uses it and has the samei·Im(x)quirk, but changing that would change how existing.hslfiles are read, so it should get its own PR.Test
A new unit test,
for_loop_summarization_complex_amplitudes, runs each loop both unrolled and summarized and requires exactly the same printed set of states:hh; tsy; h; cz; tdgAll four fail without the fix and pass with it. The existing
GroverFortest still passes, andctestpasses (2/2).I also checked against the CLI:
verexample now gives[OK]/[failed]with--loopsum, the same as without it.(H·T)^non |0⟩ for n = 1, 2, 3, 4 and 8 matches unrolling exactly. Before the fix, every n ≥ 2 was wrong and not even normalised.Not fixed here:
--loopsumhangs on multi-state preconditionsWhile testing, I found that
--loopsumnever finishes when the precondition contains more than one state, for example{|0>, |1>}with a singlex. The same happens onmainwithout this change. It is filed as #66.🤖 Generated with Claude Code
https://claude.ai/code/session_013gtFQRPe1eSSpmA7EJ2KNY