Add raw property to Unitary gate serialization

[Jacfomg]

To save the circuits from RB qiboteam/qibocal#735 with the inverse gate we would need to serialize the unitary gate as well.

Checklist:

• Reviewers confirm new code works as expected.
• Tests are passing.
• Coverage does not decrease.
• Documentation is updated.

[codecov]

Codecov Report

Attention: Patch coverage is 27.27273% with 8 lines in your changes are missing coverage. Please review.

Project coverage is 99.92%. Comparing base (19368f2) to head (e6dfb8a).
Report is 395 commits behind head on master.

Files	Patch %	Lines
src/qibo/gates/gates.py	27.27%	8 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##            master    #1277      +/-   ##
===========================================
- Coverage   100.00%   99.92%   -0.08%     
===========================================
  Files           71       71              
  Lines        10443    10453      +10     
===========================================
+ Hits         10443    10445       +2     
- Misses           0        8       +8     

Flag	Coverage Δ
unittests	99.92% <27.27%> (-0.08%)	⬇️

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.

[renatomello]

It seems you need this for RB protocol(s). Wouldn't it be easier to dump the Clifford gates directly? Then this wouldn't be needed.

[Jacfomg]

Right now, they calculated the inverse gate as:

circuit.add(gates.Unitary(circuit.unitary(), *range(circuit.nqubits)).dagger())

to only dump clifford gates I suppose we should sample also build the circuit with cliffords instead of U3s and calculate the inverse as a clifford as well. Then they will get to be U3s later so we can convert them to pulses but that wouldn't matter for the dumping I guess.

[renatomello]

I suppose we should sample also build the circuit with cliffords instead of U3s

You could use quantum_info.random_clifford for that. For one qubit, it returns a combination (IIRC up to 4) of elementary Clifford gates that combine to give all 24 single-qubit Cliffords.

and calculate the inverse as a clifford as well.
That will also be a combination of up to 4 elementary Cliffords.

Then they will get to be U3s later so we can convert them to pulses but that wouldn't matter for the dumping I guess.

If you need an $U_{3}$, you can call random_clifford(1).fuse(). Also, you don't need to dump a matrix. These are only elementary Clifford gates. The only parameter needed is their name, so just a string. You probably can get away with not using the Circuit.raw method at all.

[alecandido]

Actually, I would agree with @renatomello concerning the RB, since it is definitely better to use the most efficient representation.

But this PR could be useful in any case: if Qibo allows defining arbitrary unitary gates, we should also be able to serialize them.
Then, we could advise the users to make limited use of it, when alternatives are available (as in this case), but supporting half the way is not the best option.

Is anything missing from this PR? (other than testing) @Jacfomg

[renatomello]

Actually, I would agree with @renatomello concerning the RB, since it is definitely better to use the most efficient representation.

But this PR could be useful in any case: if Qibo allows defining arbitrary unitary gates, we should also be able to serialize them. Then, we could advise the users to make limited use of it, when alternatives are available (as in this case), but supporting half the way is not the best option.

Is anything missing from this PR? (other than testing) @Jacfomg

I understand the consistency argument. However, dumping a matrix to a dict is not a great solution overall.

[alecandido]

I understand the consistency argument. However, dumping a matrix to a dict is not a great solution overall.

Well, we can dump it as bytes with np.save. Bytes in JSON are the same bytes you would save as a standalone file. If needed, we could even encode it as base64 (supported by standard library).

It is true in general that it is better to avoid serializing a whole matrix, but if you have no other choice, that's just your best option.

[Jacfomg]

I will take a look for coding the RB with the quantum_info.random_clifford to see if we would need anything else.

[Jacfomg]

I understand the consistency argument. However, dumping a matrix to a dict is not a great solution overall.

Well, we can dump it as bytes with np.save. Bytes in JSON are the same bytes you would save as a standalone file. If needed, we could even encode it as base64 (supported by standard library).

It is true in general that it is better to avoid serializing a whole matrix, but if you have no other choice, that's just your best option.

If the agreement is this one, I will not close it. Yes, it is lacking testing if we want to merge it.

[Jacfomg]

I will take a look for coding the RB with the quantum_info.random_clifford to see if we would need anything else.

After talking with Ingo, he explained that using this function would not generate things as he wants so I will not use for RB related stuff.

[alecandido]

After talking with Ingo, he explained that using this function would not generate things as he wants so I will not use for RB related stuff.

In which way the serialization is connected to what is good for the RB?

I agree with @renatomello that using Unitary could be an overkill, but I don't see how serializing them could be different from what Ingo wants (it doesn't seem related all...).

[Jacfomg]

After talking with Ingo, he explained that using this function would not generate things as he wants so I will not use for RB related stuff.

In which way the serialization is connected to what is good for the RB?

I agree with @renatomello that using Unitary could be an overkill, but I don't see how serializing them could be different from what Ingo wants (it doesn't seem related all...).

It was not about serialization but about using the quantum_info.random_clifford function that @renatomello suggested. It will not sample as he believes it's best.

[alecandido]

It was not about serialization but about using the quantum_info.random_clifford function that @renatomello suggested. It will not sample as he believes it's best.

Ok, this is perfectly acceptable :)