Closed mtreinish closed 1 year ago
The current pattern I've found for direct symengine serialization is:
import symengine
from symengine.lib.symengine_wrapper import load_basic
input_expression = symengine.Symbol('x') * 2
data = input_expression.__reduce__()[1[0]
loaded_expression = load_basic(data)
I've opened an issue with symengine to expose this interface more ergonomically. But in the meantime this should work with both symengine 0.9.x and 0.10.x
Yes, I think this is pretty useful. I've closed my PR because of the limitation that you mentioned, but it's worth doing in terms of performance :)
What should we add?
Right now QPY solely uses sympy to represent
ParameterExpression
objects in a circuit being serialized. This is done because our preferred library for representing symbolic expressions, symengine doesn't support all the platforms that Qiskit does, so we can not always rely on symengine being available when a qpy payload is deserialized. Sympy being our fallback (and significantly slower) option is always available so it is the logical choice to serialize the expression and then if symengine is available we convert from sympy objects to symengine objects. However, while this maximizes compatibility it comes with a real runtime cost, especially for circuits with lots of unbound parameter expressions. To address this we should expose an option toqiskit.qpy.dump
to assert that symengine will always be available. This would use symengine native serialization which won't have the same runtime issues. If the deserialization side doesn't have symengine installedqiskit.qpy.load
should error saying the payload only supports installations with symengine.