FlatWaveform missing from waveforms

[bramathon]

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.

[asaites]

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.

[antalsz]

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.

[bramathon]

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?

[antalsz]

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.