You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To serialize an EvolvedOperatorAnsatz requires serializing a label containing the entire string representing the SparsePauliOp. For a QAOAAnsatz, which is a subclass of EvolvedOperatorAnsatz, this might look like exp(-it (IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIZZ + IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIZ + {...} )), where I have truncated and replaced many terms with {...}.
The problem is that this label can easily exceed the maximum allowed qpy label length of 65536 after encoding (as the label length is represented by a 16-bit unsigned integer).
In terms of code, EvolvedOperatorAnsatz relies on PauliEvolutionGate, which itself creates the label.
How can we reproduce the issue?
Create a QAOAAnsatz with many terms and over many (>100 qubits). Serialize it to qpy.
What should happen?
Somehow, no error should occur. The user should not have to modify or discard the label in order to dump to qpy. (Actually, it's not even straightforward how I'd go about discarding or modifying this label, since in order to do so I'd need to somehow access the PauliEvolutionGate through the EvolvedOperatorAnsatz.)
Any suggestions?
One of the following:
Truncate the label in a graceful way, at the boundary between two terms if the string is getting close to "too long" (which should be < 65536 characters, but possibly much less).
Modify the qpy spec to support longer labels.
I prefer the first option unless there is a strong case for keeping the entire label intact.
The text was updated successfully, but these errors were encountered:
I think there's probably two parts to the solution here:
PauliEvolutionGate absolutely should not be producing by default labels that use that many characters. It's not helpful to anybody, and I imagine it's slow to make as well - I agree we should definitely change that to something more sensible, arguably avoiding eagerly serialising the inner SparsePauliOp into a less efficient representation when the gate is created, even if we do partially truncate it - it seems very wasteful and prone to this sort of explosion. I don't use the gate, though, so I don't know what might be more useful.
QPY should have an escape mechanism to avoid hard crashing - maybe we just emit a warning on too-long labels and truncate them at the maximum length. We could consider introducing a new QPY format version to support arbitrary-length labels in some form or another too, if it's necessary.
Environment
main
What is happening?
To serialize an
EvolvedOperatorAnsatz
requires serializing a label containing the entire string representing theSparsePauliOp
. For aQAOAAnsatz
, which is a subclass ofEvolvedOperatorAnsatz
, this might look likeexp(-it (IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIZZ + IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIZ + {...} ))
, where I have truncated and replaced many terms with{...}
.The problem is that this label can easily exceed the maximum allowed qpy label length of 65536 after encoding (as the label length is represented by a 16-bit unsigned integer).
In terms of code,
EvolvedOperatorAnsatz
relies onPauliEvolutionGate
, which itself creates the label.How can we reproduce the issue?
Create a
QAOAAnsatz
with many terms and over many (>100 qubits). Serialize it to qpy.What should happen?
Somehow, no error should occur. The user should not have to modify or discard the label in order to dump to qpy. (Actually, it's not even straightforward how I'd go about discarding or modifying this label, since in order to do so I'd need to somehow access the
PauliEvolutionGate
through theEvolvedOperatorAnsatz
.)Any suggestions?
One of the following:
I prefer the first option unless there is a strong case for keeping the entire label intact.
The text was updated successfully, but these errors were encountered: