zxlive
zxlive copied to clipboard
Support basic expressions for parameterised spiders
Parameterised spiders currently support fractions of pi e.g. "\pi/2", but not more complex expressions such as (k + l) * \pi
where k
and l
are parameters. This should be achievable by storing the phase as a sympy expression.
Steps to reproduce.
- Double click on a spider and input the phase
(k + l) * \pi
Currently ZXLive will produce an error with stating the input is invalid
We already support this as all parametric angles are taken to be multiples of pi
We do not use sympy expression as we built the symbolic module in PyZX, which has some advantages over sympy
I can understand that requiring the phases to be a multiple of pi is a design decision.
Though it It seems like we cannot implement phrases such as (k + l) * pi
or (a + 1) * \pi
. Though it is possible to create two spiders, one with phase l * \pi
and the other with phase k * \pi
and fuse them together to obtain (k + l) * \pi
.
So it seems like expressions are supported, but inputting them directly isn't. So it may just be a problem with the input validation. What are the advantages of the symbolic module over sympy?
Yeah, the input parsing needs to be updated. The benefit of the symbolic module is that it allows for more integrated custom behavior. For example, we can have specific rewrites based on the type of the variable (boolean or parametric), perform automatic substitutions from custom rewrites, etc.
Double click on a spider and input the phase (k + l) * \pi
But this works without the "*pi", doesn't it? I was able to do this:
Yes, but it would be nice to allow the input to be more flexible. In fact, for symbolic values, it doesn't even make sense to ask for inputs in units of pi (unless the type of the variable is Boolean).
https://github.com/Quantomatic/pyzx/pull/234 fixes two bugs: that entering the phase as "1/2 * pi" displayed in ZXLive as 1/2, instead of pi/2, and that "pi/2" displayed in ZXLive as "1/2".
We have now discovered a new bug, that "2a+b" parses fine for some devices while on others it parses to "0a+b" independently of this linked PR. I seriously hope it's not some system-specific typing convention. Edit: Ok, someone who had "2a+b" correctly display, realized they were actually 100 commits behind for PyZX. So somewhere in the last 100-ish commits for PyZX it was broken - looking into it now.
Update on inputting "2a+b" for the phase gets auto-converted to "0a+b" with newer versions of the PyZX:
The exact change in the PyZX codebase that broke this was from commit efd400c of PyZX, i.e. the [BREAKING CHANGES] multigraph commit https://github.com/Quantomatic/pyzx/commit/efd400cf125d1f8b6c4b98f64c26a1c55609db02
screenshotted from https://github.com/Quantomatic/pyzx/compare/42343c1..efd400c
@akissinger What would break in multigraph by reverting the screenshotted change?
I think an easy change to fix this would be to do an isinstance(phase, Poly)
check instead of doing this via try and except. If I remember correctly this try/except was done by @y-richie-y when he was experimenting with using sympy in PyZX.
Or perhaps better yet: isinstance(phase,Fraction)
so that if the Poly
is replaced by something like sympy by a user, it still sortof works.
I've been playing around and note that I have to write 1/2 times x as a variable and not just 1/2x. -1 times x or -1/2 times x both seem to fail.