Open erick-xanadu opened 1 year ago
@erick-xanadu Shouldn't we be treating wire labels are static metadata/ compile time constant?
@erick-xanadu Shouldn't we be treating wire labels are static metadata/ compile time constant?
@albi3ro what would the motivation be for this? What sets your intuition on dynamic variables vs static constants?
Previously we've thought about "things that potentially trainable" like any TensorLike
as the dynamic variables. That assumption is baked into both how we write things and how we test things.
When we allow a variable to be abstract, we strongly limit the number of things we can do with it. We can no longer use it with control flow.
I also don't think we have a single test of for abstract wires.
I would be open to allowing to wires to be dynamic, but we would need time to adjust the assumptions in our code, add tests, and work through all the problems that will inevitably come up.
Hey all, just revisiting this issue now (with newer context we might have from plxpr work).
Will plxpr be treating wires as dynamic or static?
This does work with qjit
btw :)
Expected behavior
Hi,
I was testing another issue that required
work_wires
when I found that there are some quantum programs that will not be able to bejax.jit
ed when usingwork_wires
even ifwork_wires
is not required. Please note that the example submitted, when we remove the unneeded keyword argumentwork_wires=[7]
it succeeds in beingjax.jit
ed.Actual behavior
ConcretizationTypeError
is raised.Additional information
No response
Source code
Tracebacks
System information
Existing GitHub issues