APS2 and PyQLab

[lumip]

In discussion #7, @hbluhm referenced the documentation of the Raytheon BBN Technologies Arbitrary Pulse Sequencer 2 as a device to be considered as well as the PyQLab project maintained by the manufacturer.

Having taken a look at both, it seems that this should integrate reasonably well with the sequencing scheme proposed in #27. The APS2 relies on an instruction set similar to the one we intended to use with some extended functionality. Expanding our instruction set to cover this should be feasible.
The PyQLab project introduces a Quantum Gate Language (QGL) which essentially is an object representation of pulses somewhat comparable to the approach we choose. We might be able to extract some useful ideas from there.

The main difference in pulse representation is the following:
Our approach currently allows users to define pulse templates with optional parameters. We allow nesting using the Composite pattern to feature reuse of already existing templates. This approach allows to create new templates without creating new classes, i.e., without the need to create source code.
PyQLab's approach is create a class if a new pulse template is required and it already provides a set of common templates. Parameters are not encoded into objects as in our approach but rather passed to the template classes during their instantiation. This is a bit simpler than our approach but requires to create a new class (with all required methods to comply with the pulse interface) for each new template and might make reuse of existing template harder. It may be a bit compacter to use in an experiment though (cf. this demo).
Nevertheless, my judgement is that our approach provides more flexibility, so I would recommend we stick to it. Any thoughts @qutech/bluhm-group @qutech/owners ?

[lumip]

The main addition of the APS instruction set would be functions calls. We currently have no representation for this in the PulseTemplate hierarchy and I'm not sure whether it is needed. Thoughts?

[hbluhm]

Not sure. In principle "inline functions" could probably do the job, and memory may not be an issue.
I have a sense that they might become quite useful for composing pulses from many small bits and pieces, which may be needed/advisable because of the memory model of the APS2. Functions would also make the code sent to the machine more readable, but then it's not clear that anyone will ever read that. Perhaps another item to keep in mind without implementing it yet.

I also find the flexibility and power of the approach taken so far attractive. The objects of QGL feel a bit like what we are coming from, and it's not clear that it will conveniently extend to longer algorithms. Having said that, the QGL syntax for the sequences is pretty neat.