Closed alecandido closed 7 months ago
@stavros11 @PiergiorgioButtarini @hay-k @Jacfomg while replacing the subclasses by using Pulse.type
attribute, I realized that even that might be superfluous.
Essentially, the type of the pulse is telling you where this object will be played on. I have two similar objections to this procedure:
Pulse.channel
, so we could well retrieve the information from thereSo, as a first proposal, we could try to identify the type using the channel. Later on, we could try to kick the channel (and qubit) out of the pulse (as @hay-k was also suggesting at some point, or something close to) and move this information somewhere else (potentially the sequence).
The second step is less appealing, because it's just moving the complexity from one place to the other. Still, it could help to better isolate the components.
Attention: 7 lines
in your changes are missing coverage. Please review.
Comparison is base (
dea5405
) 61.84% compared to head (f10ba3a
) 61.72%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
- there is already such an attribute, it is the
Pulse.channel
, so we could well retrieve the information from there- it doesn't really make the difference whether a rectangular pulse is a drive or readout pulse, they are both rectangular, and they can have similar parameters
I believe both these points are right, it is redundant to have both type
and channel
. However, the main issue right now is that not all drivers are using pulse.channel
. Some are looking at pulse.qubit
to know where to play the pulse (mostly my fault) and in this case pulse.type
is needed.
In any case I would proceed PR since it is at least removing a third redundancy (the subclassing) and for sure come back to the channel
issue later.
In any case I would proceed PR since it is at least removing a third redundancy (the subclassing) and for sure come back to the
channel
issue later.
Agreed. I raised the question because it became relevant.
My current goals are to seize the low-hanging fruits first, and to greatly reduce the complexity of pulses.py
with things that mostly regard only pulses.
As soon as that will be close to completion (hopefully next week) I would try to start examining the interactions between pulses and everything else (qubit and channels are relevant, but most likely native are easier, so I'd start there).
@stavros11 @PiergiorgioButtarini @hay-k @Jacfomg while replacing the subclasses by using
Pulse.type
attribute, I realized that even that might be superfluous.Essentially, the type of the pulse is telling you where this object will be played on. I have two similar objections to this procedure:
* there is already such an attribute, it is the `Pulse.channel`, so we could well retrieve the information from there * it doesn't really make the difference whether a rectangular pulse is a drive or readout pulse, they are both rectangular, and they can have similar parameters
So, as a first proposal, we could try to identify the type using the channel. Later on, we could try to kick the channel (and qubit) out of the pulse (as @hay-k was also suggesting at some point, or something close to) and move this information somewhere else (potentially the sequence).
The second step is less appealing, because it's just moving the complexity from one place to the other. Still, it could help to better isolate the components.
It makes sense since we have the Pulse.channel
, but when I wrote the Zurich driver I made use a lot of the Pulse.type
. Btw, since we plan on changing the Pulse
maybe we could get rid of the example notebook.
Use the
.type
attribute instead, which was already present (and they were quite a duplicate of each other).Moreover, the
.copy()
and.shallow_copy()
method of the pulse class have been removed, since they were mostly required to deal with the subclasses themselves. As a replacement, thecopy.copy()
andcopy.deepcopy()
standard library functions are suggested.