Skip to content
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

Remove on_classical_vals for CSwapApprox? #1527

Open
anurudhp opened this issue Jan 24, 2025 · 3 comments
Open

Remove on_classical_vals for CSwapApprox? #1527

anurudhp opened this issue Jan 24, 2025 · 3 comments

Comments

@anurudhp
Copy link
Contributor

CSwapApprox is a CSwap upto a relative phase, and therefore not classical (xref #1515)

Currently CSwapApprox is used by SwapWithZero which is in turn used by SelectSwapQROM. So removing the override breaks the classical simulation tests for the latter bloqs.

@mpharrigan
Copy link
Collaborator

I personally agree with the premise, i.e. we should probably use normal swap by default everywhere and for testing and if we need the resource savings we can swap (heh) it in through an attribute on the bloq that uses it. wdyt @tanujkhattar

@tanujkhattar
Copy link
Collaborator

I think this pattern will become more important as we add more relative phase versions of bloqs. For example, we want to have Toffoli gate implementation that's correct upto a CS relative phase.

Using these bloqs for resource savings will be essential as part of defining the bloq decomposition and its not trivial to "swap out" automatically. For example, if you have a multi control Toffoli decomposition using a ladder of n - 1 Toffolis that appear in compute / uncomputer pairs and a 1 Toffoli in the middle that does not appear in a pair, then we can replace the toffolis that appear in compute / uncompute pairs using a relative phase toffoli but the 1 in the center would have to be a normal Toffoli and we can't use the phase incorrect version there (assuming we are not implementing a phase incorrect multi control Toffoli)

In general, having the ability to specify classical action for bloqs that are almost classical is useful. Also, going forward, more decompositions should have specific phase incorrect versions of bloqs to get concrete compilations and resource estimates.

If I understand correctly, the problem that this causes is that it makes it harder for us to automatically infer the my_tensors of a bloq using its classical action. But shouldn't that be an explicit opt-in that we can choose not to do when defining a bloq ?

@mpharrigan
Copy link
Collaborator

For #445 and #65 I'm adding a protocol that lets you simulate phased classical action, which would explicitly annotate this case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants