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

Allow generic wavefunctions as initial_state #371

Merged
merged 1 commit into from
Nov 14, 2024

Conversation

ohuettenhofer
Copy link
Contributor

This pull request depends on #370.

For the Qulacs and Qiskit backend, it makes it possible to initialize circuits with arbitrary wavefunctions instead of only basis states.
This also adds the parameter for sampling and to tq.simulate.

I have added boolean flags to the backend circuit objects that indicate which backends support this and throw an error message when necessary. This doesn't seem ideal, but I didn't want to change the other backends that I can't test.

Also, combining initial states with a keymap is awkward, I think it only makes sense if we assume that all states on the inactive qubits are the same. For now I disabled it and throw an error message.
I noticed that there's no keymap for sampling, can we get rid of it for simulating too?

Example usage:

import numpy as np
import tequila as tq
from tequila import QubitWaveFunction

U = tq.gates.H(target=0)
state = QubitWaveFunction.from_array(np.array([1.0, 1.0])).normalize()

result = tq.simulate(U, initial_state=state, backend="qulacs")
assert result.isclose(QubitWaveFunction.from_basis_state(n_qubits=1, basis_state=0))

result = tq.simulate(U, initial_state=state, backend="qulacs", samples=100)
assert result.isclose(QubitWaveFunction.from_array(np.array([100.0, 0.0])))

@kottmanj
Copy link
Collaborator

Should be fine (failed test is probabilistic and has nothing to do with the changes here). I Accidentally created some conflicts by squashing commits from the previous PR. Sorry :-)

@ohuettenhofer
Copy link
Contributor Author

ohuettenhofer commented Nov 14, 2024

The conflict should be resolved, but I don't think there was a way to avoid this conflict. The alternative would be for me to keep the history clean directly so squashing isn't necessary, but then I have to rewrite the history every time I push a small change.

@kottmanj
Copy link
Collaborator

usually doesn't happen that much. You were just faster in development than I was with merging :-)

@kottmanj kottmanj merged commit e32d885 into tequilahub:devel Nov 14, 2024
11 checks passed
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

Successfully merging this pull request may close these issues.

2 participants