Quilt spec improvements #46
Conversation
With parametric compilation, we can handle mixed real + parameter arithmetic in frame mutations. However, if parametric compilation were not available, then arguments to frame mutations would need to be immediate/literal real values.
|
RE parametric waveforms: What are the negatives of keeping them? Are they complicated from an implementation perspective? I'm not against holding back a feature because it's not useful, but I wonder if it might end up being a nice-to-have and does it cost us much to implement? |
The negatives are just that they aren't currently implemented, the proposed syntax is caught between the Quil circuit style and the Quilt template waveform style, and as far as I can tell there is not a clear case for this feature. I think if we want to include something like this, there needs to be more thought about it. For example, what might even be more useful is to develop the notion of "waveform expressions", e.g. something like This was also suggested by the spec, but never made explicit, and would require some clarification around what sort of expressions are allowed and how they are to be evaluated. What I hoped to do by removing these is not to keep them out of the spec forever, but simply to turn the tables and get some clarity and motivation on these features before standardizing them. I would hope that e.g. Rigetti would be able to experiment with these even before they are made officially part of the standard. |
| Some examples of the template waveforms made available by Rigetti include: | ||
|
|
||
| ``` | ||
| Waveform :: flat '(' duration: Expression, iq: Expression ')' |
There was a problem hiding this comment.
Should this block be examples in quilt rather than in unimplemented grammar?
* Update proposal.md using pyquil quilt-demo branch changes * Merge pyquil Quil antlr grammar * Remove TODO item * remove duplication
Starting this as a draft, but this is intended to address #45 + whatever related follow up is appropriate. cc: @stylewarning who may have an interest in these changes.
Aside from typo fixes, there are a few more significant changes.
Clarification around standard vs implementation-specific features
The body of
DEFFRAMEcontains "frame attributes", some of which are sensible to standardize (e.g. every frame has anINITIAL-FREQUENCY), whereas other attributes may be specific to a hardware implementation.The "template waveforms" may be considered vendor specific. This is because the specific templates available may depend on the Quilt translator (if statically resolving waveforms) or the specifics of lower level control software and hardware. Likewise, even for seemingly standard shapes, like a gaussian, there may be constraints on the template parameters (e.g. perhaps on some hardware these may refer to memory regions, whereas for other hardware they must be constant).
Removal of parametric DEFWAVEFORM and waveform expressions
I'm also suggesting to remove parametric waveform definitions, i.e.
DEFWAVEFORM foo(%bar): .... The reason for this is twofold:foo(a: 1, b: 2), since these are much easier for a human to reason about. This is slightly at odds with the originally proposed syntax around parametricDEFWAVEFORM, which was intended to mirror that of parametric gates.SET-SCALE) or adjust accordingly during readout (e.g. an additive shift there). I don't see practically how someone would do something more complicated than this: certainly they aren't going to write 1000 expressions by hand, and if designing a waveform in MATLAB or numpy they will just end up dumping the samples directly.For similar reasons, I changed an example in which a waveform was used as part of an algebraic expression representing "vectorized arithmetic" of some sort.