Split RX from RXY

[alecandido]

Unfortunately, the RXY name is non-standard, but I was lacking a better one.
Any suggestion? @stavros11 @andrea-pasquale

• restore some validation?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 52.10%. Comparing base (26df7f2) to head (195f9ce).
Report is 10 commits behind head on 0.2.

Additional details and impacted files

@@            Coverage Diff             @@
##              0.2    #1050      +/-   ##
==========================================
- Coverage   52.34%   52.10%   -0.24%     
==========================================
  Files          63       63              
  Lines        2820     2806      -14     
==========================================
- Hits         1476     1462      -14     
  Misses       1344     1344              

Flag	Coverage Δ
unittests	52.10% <100.00%> (-0.24%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[andrea-pasquale]

Unfortunately, the RXY name is non-standard, but I was lacking a better one. Any suggestion? @stavros11 @andrea-pasquale

I was discussing with @stavros11 about this yesterday. What about just R or Rn?

[alecandido]

I was discussing with @stavros11 about this yesterday. What about just R or Rn?

To be fair, I'm not even completely sure that it should be a native. I see it better as a compilation rule, since the native should just store the calibrated pulse.

However, by now I'm entering more and more in feature freeze mode. If there is a sufficient agreement about the above statement, it will become an issue for 0.3, and that's it (this "parametrized pi-pulse" is there since months, and I won't change the last day before release).

For me, all names are good enough, just tell me your favorite (one for which there is some consensus), and I can change it.

[stavros11]

I was discussing with @stavros11 about this yesterday. What about just R or Rn?

I would say R is fine. It is simple and doesn't really introduce new physics.

To be fair, I'm not even completely sure that it should be a native. I see it better as a compilation rule, since the native should just store the calibrated pulse.

I actually think the proper solution is this, have only the RX (with fixed amplitude and zero phase) as native. However, the side-effect is that then the user (mainly qibocal) would have to do the pydantic gymnastics (tune the amplitude, change the phase) to get the other rotations. Which is not necessarily bad, we just need to get used to it.

Generally, I would only call natives what we are actually calibrating. If we are calibrating the RX90 directly I would then call it native, but unfortunately I don't think we have support for that in 0.2, native kinds are fixed. If we need to further manipulations to get other gates, I would do them outside the Platform.

[alecandido]

I would say R is fine. It is simple and doesn't really introduce new physics.

Ah, wait, maybe that name is the one already used:
https://docs.quantum.ibm.com/api/qiskit/qiskit.circuit.library.RGate

[alecandido]

I actually think the proper solution is this, have only the RX (with fixed amplitude and zero phase) as native. However, the side-effect is that then the user (mainly qibocal) would have to do the pydantic gymnastics (tune the amplitude, change the phase) to get the other rotations. Which is not necessarily bad, we just need to get used to it.

Generally, I would only call natives what we are actually calibrating. If we are calibrating the RX90 directly I would then call it native, but unfortunately I don't think we have support for that in 0.2, native kinds are fixed. If we need to further manipulations to get other gates, I would do them outside the Platform.

I perfectly agree with you, but I'd also like to save whichever user the gymnastics you mentioned.
Since we already have a proposal to expose the compiler in a smoother way #1042, let's first do that, and then we will reconsider also this method.

[alecandido]

• restore some validation?

There is no strong reason why single qubit gates should be single pulses or applied on individual channels.
True, RX is usually the pi-pulse. But if any user wanted to add something else, it's not necessary to deny it.

Let's just leave it to users' responsibility.

[stavros11]

Thanks @alecandido, looks good to me.

[stavros11]

In principle, we could leave the Args: structure in the docstring here, as it was before.

[alecandido]

Yes, we could.

This is something I'm doing on my own: frequently the Args: (and equivalents) contain redundant information (essentially repeating the variable names), and redundant type hints.

It was not the case of this docstring in particular, as it is essentially unchanged. But I'm trying to keep the style more discursive.
However, I'm not pushing to enforce it. Not now, at least.

[alecandido]

@andrea-pasquale is it fine for you like this?

[andrea-pasquale]

Yes, fine by me. Just a tiny suggestion.

[alecandido]

I'm merging as soon as the CI will pass