Support for ExplicitPredicate, ExplicitModifier, MultiBitOp
#162
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
feat: add support for ExplicitPredicate/Modifier & MultiBitOp
qartik
requested review from
cqc-alec and
neal-erickson
and removed request for
cqc-alec
qartik
force-pushed
the
159-expand-classical-ops
branch
from
09970f6
to
53195fc
Compare
qartik
force-pushed
the
159-expand-classical-ops
branch
3 times, most recently
from
c466dc9
to
798ef4b
Compare
qartik
force-pushed
the
159-expand-classical-ops
branch
from
798ef4b
to
f7f2c26
Compare
| return { | ||
| "cop": "&", | ||
| "args": [ | ||
| {"cop": "==", "args": [arg_to_bit(arg), bval]} |
There was a problem hiding this comment.
Need to be careful of endianness here. The conditional value in pytket is little-endian, e.g. a value of 2 on the bits [a[0], a[1]] means a[0] == 0 && a[1] == 1. Does PHIR use the same convention?
There was a problem hiding this comment.
@qciaran would you be able to confirm. I forgot to mention you at #162 (comment), I also had my doubts.
There was a problem hiding this comment.
I agree though that the default choice should be little-endian here. While Ciaran confirms, I am pushing the change to update the behavior.
There was a problem hiding this comment.
@cqc-alec although I wonder if the bits are explicitly specified like:
condition_bits=[Bit("b", 1), Bit("b", 2)],
condition_value=2,
ie, [b[1], b[2]] == 2 (pytket translation of above in the phir comment), is the intention from pytket still that they will be reordered and considered little-endian? I'd imagine the user to write condition_bits=[Bit("b", 2), Bit("b", 1)] if they wanted b[2]=1 and b[1]=0.
There was a problem hiding this comment.
Yes that is the intention: the order in which the bits are given corresponds to the little-endian binary expansion of the value. In your example, the condition is b[1] == 0 && b[2] == 1.
There was a problem hiding this comment.
Yeah, in PHIR a[0]==0 && a[1]==1 is the integer value 2. Or: {"cop": "=", "args": [2], "returns": ["b"]} results in b[0]==0 & b[1]==1
Sounds like that should be mentioned in the spec, womp womp.
There was a problem hiding this comment.
Filed CQCL/phir#77, this PR seems ready to be merged.
Co-authored-by: Alec Edgington <54802828+cqc-alec@users.noreply.github.com>
qartik
changed the title
ExplicitPredicate, ExplicitModifier, MultiBitOp`
qartik
changed the title
ExplicitPredicate, ExplicitModifier, MultiBitOp`ExplicitPredicate, ExplicitModifier, MultiBitOp
Description
Expand support for custom tket classical operation types in phir
Fixes #159, closes #25
Type of change
Checklist