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

Add separate method to do wavefunction simulation #326

Closed
maffoo opened this issue Apr 23, 2018 · 3 comments
Closed

Add separate method to do wavefunction simulation #326

maffoo opened this issue Apr 23, 2018 · 3 comments
Assignees

Comments

@maffoo
Copy link
Contributor

maffoo commented Apr 23, 2018

The current simulator interface and behavior mimics interface to hardware, where we run multiple repetitions of a circuit and get back measurement samples for each repetition. The simulator also returns a list of "final states", one for each repetition, which are the final wavefunctions. However, the final states are not particularly useful if you have measurement gates, since you get the post-collapse state. And doing anything more than one repetition when you want the wavefunction is a bad idea because the wavefunction will always be the same (if there are no intermediate measurements). I think it would be good to clean up this interface. One idea would be to have a completely separate method to run a simulation and get out wavefunctions, which would not take a repetition count. Another possibility would be to just add additional arguments on the existing run methods to control whether to return the final wavefunctions. I would vote for a separate method to do wavefunction simulation, but I'm curious what other people think.

@dabacon
Copy link
Collaborator

dabacon commented Apr 23, 2018

Yeah I ran into this when trying to do the optimization for repeated measurements at end of circuit. (pull request out but I need to revamp).

I think I'd lean towards making it more explicit by having a separate call when you want to get the full wave function.

@Strilanc
Copy link
Contributor

I agree that we should have separate methods for different kinds of results. Methods whose return type depend on their arguments in complicated ways are no fun.

@dabacon dabacon self-assigned this Jun 6, 2018
@dabacon
Copy link
Collaborator

dabacon commented Jun 18, 2018

Fixed in #456

@dabacon dabacon closed this as completed Jun 18, 2018
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