rigetti
FlatWaveform missing from waveforms
The quil.waveforms module exports the following symbols.
"BoxcarKernel", "ErfSquare", "Gaussian", "DragGaussian", "HermiteGaussian", "apply_phase_and_detuning",
However, pyquil.quiltwaveforms exports:
FlatWaveform, GaussianWaveform, DragGaussianWaveform, ErfSquareWaveform, HrmGaussianWaveform, BoxcarAveragerKernel
The difference is that quil.waveforms is missing FlatWaveform which is frequently used in practice.
As you've found, I don't believe there's a FlatWavefrom equivalent. That said, the waveform classes in quil-rs seem to have several differences in implementation relative PyQuil, with respect to how you would get a numpy array out of them. In particular, BoxcarKernel in quil-rs has into_iq_value that can only return a single complex number, static once the BoxcarKernel is constructed.
The quil.waveforms module is really kind of an atavism or something; it's not used anywhere in quil-rs, and barely provides any functionality. The structs are really functioning as named parameters for into_iq_values, and aren't used for anything else – and quil-rs never thinks about IQ values. We have thought about maybe doing some revamping of this module; what prompted issue, and what's the context where you need flat waveforms? If you're just constructing their IQ values, [iq] * duration is probably easier.
I was trying to write a plotting function which depended only on quil-py/quil-rs, not pyquil. However, in order to plot the waveforms, I need these functions.
However, it's clear that the translator knows the definitions of the waveforms, and I was under the impression that this was the source of truth. If Flatwaveform is not present though, that can't be true. What is the source of truth for waveform envelopes?
Thanks, that's helpful context! As you have learned, quil-rs is not really waveform-aware – there's nothing in quil-rs that actually thinks about what waveforms mean, they're treated as opaque blobs. There's not really a single source of truth for waveforms at the moment 🙃
I agree it would be good to get this stuff centralized somewhere; as I mentioned in terms of thinking about a rewrite of this module, we'll make sure that if/when that happens it can support your use cases.