-
Notifications
You must be signed in to change notification settings - Fork 16
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
Parameterized measurement patterns #45
Comments
Hey! |
Hi @pafloxy! sorry for the delay responding.
yes exactly - and thanks for pointing out about the link:)
My opinion is that it would be best to have a new class (some simplified version of qiskit implementation I imagine) here, for better maintainability. I agree we would need new methods in |
Though I am well acquainted with the |
methods like |
Hello again. I was still working to get this done, so for now I was trying to get a skeleton structure of the parameterization using the qiskits But anyway, i had one question again. As it seems one is supposed to use don't you think we should somehow freeze such attributes and intoroduce methods instead to change them. This might be impotrant in our case becasue upon appending a measurement command we need to be certain if it is parameterized or not. I undersand that Also I think it would be possible to partially simulate the measurement pattern as well incase we make sure that for every qubit over which the measurement command is to be simulated, all qubits sending correction to that qubits must have a values assigned to their parameter as well ? Let me know what you think of this. :) |
@pafloxy Hi, thanks for these nice progress and I agree we really should start using
yes indeed, we need to treat parameterized nodes as non-Pauli-measured node which you cannot preprocess.
I personally think we do not need to worry about such case for now - I believe standard quantum-classical algorithms like QAOA update parameters at once before each 'quantum' step?
I do not fully understand the case considered, but for simplicity I think we can ask for all the parameter to be assigned a value before simulated. As you say, it would be nice to be able to step into the pattern simulation (say stopping in the middle of pattern execution and inspecting the state vector, etc c.f. #35). |
Thank you for reading my comments,
Yes that is usually the case, however I was considering parameterized measurement patterns in their general sense than just the measuremnt patterns generated by translating directly from usual variational circuits.
Yeah that could certainly be the case but actually I thought it would be more general to consider the case where not all the parameters are assigned numerical values. Since the resource state preparation posses no parameterisation the only issues can arisr from simulating measurements. Problems in such a case would arise if we are to simulate the measurement on a node which recieves correction from node which has a paramterised measurement angle. But I think this could be avoided easily. For a pattern to be simulatable, we can restrict the order of parameter assignment in the same fashion as dictated by the flow conditions, then we will never end up in a case like the one above. For ease of computations we can simply add some slight restrictions, say we can restrict value assignment such that nodes in layer ** layer
|
thanks for your reply, I might add one comment here. The byproduct correction is not dependent on the angle of the measurement basis, if the plane (e.g. XY, YZ) is fixed. It is indeed not impossible to make the measurement plane parameterizable but I personally think that would be an overkill for now. Parametrising the measurement plane and making it dynamic during execution means the choice of byproduct command (being one of X, Z or XZ) will also become adaptive - and this makes process like standardization a lot more complex. |
I understand that. But what I meant was that even if we stick to just XY plane measurements we still have to decide wtheter the measuremnt result was 1/0. And uptil now I assume that only nodes with measurement angle assigned would be measured. So if the byproduct on a later node is affected by the the measurement of a parameterised node we won't be able to simulate the measurement on the later node. Isn't that right ? I'll be glad if you can clarify :) |
@pafloxy Okay now I see the situation you were considering! So you were thinking of a case where you have parameterised measurement commands in the pattern, and want to execute with parameter kept as a placeholder, and once execution reached this command you skip over the it to move to next one, leaving the measurement signal of skipped-over measurement also a placeholder. I do not think such a case is realistic - any measurement command that depend on this 'placeholder measurement signal' cannot be performed because you cannot determine the measurement angle (it could be possible by popping out such signal as X or Z commands and moving it around somehow, but perhaps not very likely). What you can do instead is to defer the parameterised measurement by moving the command towards the end of the pattern, following commutations rules, and while keeping eye not to move past measurement command that depend on the signal from it. Please let me know if I understood your intention correctly, and feel free to ask further questions. |
Actually my intent was exactly to avoid this scenario by not allowing measurement of nodes that recieve corrections from paramterised nodes, unless numerical values have been assigned to all such parameters. And I wasn't really thinking of keeping placeholder for measurement results as to me they seems a bit complicated to reason about.
Yeah that was similar what i had in mind. But to make the task easier I suggested that we can use the layered structure of the graph due to the partial order (i'll assume we number them from the input to the output i.e input layer -> l= 0). Say to simulate the measuremnts upto layer l = l', it is sufficient to have that all measurement parameters for nodes in l=0 to l= l'-1 has been assigned. I undertand that you have methods to make the dependency beteween nodes more explicit i.e via the Let me know if I'm wrong at some point. |
I think you're totally right, we can indeed do that! Other than |
@pafloxy |
I see. I remember reading in your paper that flow isn't conserved upon the Pauli Optimisation scheme the paper introduces but yet it is still deterministic. But wasn't gflow a necessary condition for determinism ? |
the way we preprocess the Pauli measurement is by 'running' the pattern on the graph state simulator, instead of rewriting the pattern, for faster processing. Because we also preprocess measurements on the input node (if it is Pauli-measured), I am not aware of general proof that resulting graph should have gflow (though it's quite possible that it is the case for most graphs). Determinism is guaranteed by the determinism of the pattern before the proprocessing. Either way, we wanted to make sure More importantly, perhaps, the dependency layer you get from So, I would think it's best to trust |
I see, Actually to my knowledge I undesrtood the "flow" conditions to be the only criterion to be satisfied for determinism, maybe I should have alook at the reference for graph state simulator at M. Elliot, B. Eastin & C. Caves. Most probably you are right, but I will just need some time to think about it, in a theoretical perspective, most probably I'll get back with some questions. Sorry about that : / But as for the code design I think we can proceed to a certain extent. |
|
That's for sure, but incase we already instantiate the For example something like this pat = Pattern(4, output_nodes= {0}) And I think this would have caused you problems in the |
I see, that’s a good point. Would it work if we change the implementation of generate_from_flow, such that we don’t initialise Pattern with output_nodes specified and let add function take care of it? |
|
sorry, that was a typo, I meant |
What I rather think is that we should remove the We can simply raise an error when user tries to And yes we will need to freeze the attribrutes like |
I also realised that the deadline to make PRs and to be eligible for the bounty would be within just a day, which ovbiously won't be sufficient for me to completely implement the required things 🥲 . And I don't reallly want to make it in a rush and turn in it into something not very useful by the end. But I belive you will agree that I had to do some hard digging to find out all such small issues here and there, so I would be glad if there is an workaround to the deadline thing. I remain interested in developing the code concerned either way since it is important for my own work somehow. 🙂 |
@pafloxy re unitaryhack, let met first assign you to the issue, and if you could quickly open a draft PR (perhaps add the draft implementation with qiskit module there to show it's in progress), that may also help. I will then talk to UnitaryHack admin to ask how to proceed in this kind of case. let me answer the earlier comment later today. |
I can do that, but I have it in a notebook since it was just about trying things out, than to directly intergrate it into the code. I think at this point it iis better that I write it in words rather than to modify the code directly, since I will need to some methods in the |
regarding the hack - the admin said you have until 20th June to complete PR to be eligible for the bounty. |
I see, I'll try to get to it. What about the modification suggested to the I think we'll need to settle such small things first, to get it done by the deadline 🙃 |
Sorry for the delay responding re the add method!
Agreed, I think it’s better not to do
Also agreed. That would be a good way I think, I look forward to seeing the implementation which would give better sense of how it goes.
Yes, we would need to freeze the seq attribute. |
@pafloxy Hi, I just want to mention that upgrading of |
Thanks foe letting me know. I'll be glad if that is pushed to the repo, so that I can be sure of not making any condflicts from my end! |
@pafloxy he said it's not ready to be pushed yet, but we can confirm what you suggested seems not to conflict. going back to some earlier discussions,
we think |
I see I will then change it so that it doesn't raise an error, though I did miss to think about the tracking of nodes and qubit, probably I will need to fix it, thanks for reminding. Otherwise as it seems everything else has been put in place and seems to run smoothly and I might be able to demo it shortly. Yeah you are right. My idea was to consider more general measurement patterns than could be obtained from circuit, as we discussed. But yeah we can leave it for later. However, I am not really sure about designing the new "Parameter" class as required, since my implementation involves properties of the |
Hi @pafloxy! I am afraid I would rather want to keep this package independent from qiskit. Adding dependency for the sake of non-core feature is, in my opinion, not good for maintainability (noting qiskit is version 0.* which indicates the possibility of breaking changes according to semantic versioning) and as it's circuit-based package, it may dilute the meaning of our package. As I said, we can keep to MVP and evolve it in the future - having interactivity is nice indeed, but it’s not essential to demonstrate QAOA, for example. Just being able to assign value at the start of simulation stage (no need to change them during execution for now!) is enough for now. Finalizing such minimal implementation with high standard and making sure it works for wide variety of situations is already a lot of work, and we can improve it step by step from there :) |
I understand, so what I noticed is that the Will such an implementation work ? Its good for me as everything on the outset still remains the same, and maybe it can pave way to a better over it in future. Let me know what you think ;) |
thanks for the comment, I would like to see the implementation, please do push it (if it's notebook that's also fine) when you're ready :) I will then give it a comment or edit myself. |
Hi! Sorry for replying so late, I was actually caught with things on my personal side. You can find an illustration at https://github.com/pafloxy/graphix_pafloxy/blob/master/parameterised_measurement_demo.ipynb, of the assignement procedure for parameterised circuits and patterns. |
thanks! could you create another fork and add the changes you did to pattern.py only (ie no notebooks, no parameter.py etc)? I will then re-implement the parameter related classes on your fork and create PR on your fork. I can do this today, and we can finalise over tomorrow and the day after and create new PR to graphix master. |
The current implementation only allows the creation of measurement patterns with a fixed set of parameters (rotation angles). However, for quantum-classical algorithms such as VQE or QAOA, it is desirable to run many identical quantum circuits (patterns) with differences in the rotation parameters only. For this, it would be ideal to have the option to create parameterized measurement patterns whose rotation angles can be changed after transpilation and optimizations (standardization, signal shifting, Pauli measurement preprocessing, and more).
For this, I propose to:
Parameter
class in a new filegraphix/parameter.py
to instantiate parameter objects (c.f. qiskit parameterized circuit), which has parameter name and bounds (we assume them to be real values).graphix.transpiler.Circuit
class to accept parameterized rotation anglesgraphix.pattern.Pattern
andgraphix.simulator.Simulator
classes to ask for parameter value substitution when running the pattern as keyword argument, if there are parameterized commands.graphix.pattern.pauli_nodes()
to consider parameterized measurement commands as non-Pauli measurementsgraphix.pattern.Pattern
to inspect parameterized patternsI may be missing other fixes and additions that need to be done to make this feature work, which I would be keen to discuss on this issues page.
Please see our contribution guide before starting, and do not forget to comment on this issue to show your interest. We are always happy to answer questions, so do not hesitate to ask on this page.
Thank you for your interest, and good luck!
The text was updated successfully, but these errors were encountered: