Closed BorisVarbanov closed 6 years ago
Gah, this is what happens when you hack together a solution to something and then it gets adjusted slightly and the hack fails.
@slavoutich - this is a problem that requires a good fix rather than just me trying to patch it together again. The issue is that the measurement outcomes need to be stored somewhere that the controller can find them (and the controller doesn't usually have knowledge of which gates are measurement gates). Traditionally we've used classical bits for this, but then the question gets raised, what if the user makes measurements onto multiple classical bits - how do we tell the controller which bit to read from? I think what might be an option is to have the qubit objects store their measurement history, can you think of anything better?
@BorisVarbanov I would be thankful for minimal snippet, that demonstrates a bug.
Ah, sorry, I see the problem, snippet is in the tutorial. I should read messages better :)
This is a good point - it's easier for everyone to see where the problem lies when there is a snippet attached. I'll try to illustrate errors better in the future. But since you already found it in the notebook, I won't attach the snippet here. Thanks for looking into this.
I think that idea of storing some history in qubits is not so cool, it is better to be stored somewhere in controller..
the controller doesn't usually have knowledge of which gates are measurement gates
What do you mean? Its initializer recieves measurement_gates
parameter explicitly. Another thing is that they might better be separated from usual gates (for example, having the same parent class, like IdlingGate
), since in general they are quite special.
Speaking about real issue, as I see, there are two ButterflyGate
s after two Measurement
gates. As far as I understand, this should be opposite, and that is the real source of theproblem, right?
I think that there is an architectural problem: each call to quantumsim's Measurement.apply_to
modifies the gate implicitly. This should go to the level of experiment controller or similar, circuits should behave like an operator and nothing more. I can try to monkey-patch this, but better solution would involve some major reshuffling of everything around.
What do you mean? Its initializer recieves measurement_gates parameter explicitly. Another thing is that they might better be separated from usual gates (for example, having the same parent class, like IdlingGate), since in general they are quite special.
Fair point - I guess what I mean is that it's difficult to get the measurement gates from qsoverlay. And the architectural problem that you mentioned.
circuits should behave like an operator and nothing more. Agreed completely.
I'll think on a better solution overnight and get back to you.
Issue is fixed by #7, everything else is a matter of another issue.
When doing measurements, applying the circuit (and more specifically the measurement gates) results in an AtributeError. That is due to the an expected probabilities attribute, which the ButterflyGate object from quantumsim does not have. This is encountered in the last cell of the notebook. @obriente