Add partial_transpose to quantum_info.linalg_operations

[renatomello]

Needs to be merged before #1456

Checklist:

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

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.93%. Comparing base (9fb5161) to head (7f33911).
Report is 19 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1462   +/-   ##
=======================================
  Coverage   99.93%   99.93%           
=======================================
  Files          81       81           
  Lines       11750    11777   +27     
=======================================
+ Hits        11742    11769   +27     
  Misses          8        8           

Flag	Coverage Δ
unittests	99.93% <100.00%> (+<0.01%)	⬆️

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.

[BrunoLiegiBastonLiegi]

I think it might be useful to allow the inputs to both partial_transpose and partial_trace (this one in a separate PR though) to be batches of states, similarly to what it is done for vectorization in #1459. This would make more efficient, for instance, the calculation of the meyer_wallach_entanglement

qibo/src/qibo/quantum_info/entanglement.py

Line 196 in 165b204

def meyer_wallach_entanglement(state, backend=None):

and similar methods that need to perform these operations on several different states.

[renatomello]

I think it might be useful to allow the inputs to both partial_transpose and partial_trace (this one in a separate PR though) to be batches of states, similarly to what it is done for vectorization in #1459. This would make more efficient, for instance, the calculation of the meyer_wallach_entanglement

qibo/src/qibo/quantum_info/entanglement.py

Line 196 in 165b204

def meyer_wallach_entanglement(state, backend=None):

and similar methods that need to perform these operations on several different states.

Done.

[renatomello]

@AlejandroSopena @stavros11 this is ready. Could you review it soon since it is blocking #1456 ? Thanks

[stavros11]

Thanks @renatomello. Generally fine with me, but I have not checked validity so I just trust the test.

It took me some time to understand the supported input shapes and I think we are kind of overcomplicating it by supporting 1-dimensional arrays. To me, since this is a partial trace, it would even be sufficient to stick to 2-dimensional. If someone wants to process a 1-dimensional one, they can still do the outer product before calling this (this way it is also a bit more modular). However, I am not the best candidate user of this, so it's not a strong opinion.

Other than that, I understand you are also supporting a "batch" dimension (N). There may be a way to generalize this to arbitrary number of batch dimensions ((..., k, k)), so that you don't even have to distinguish between batch/no batch, but I haven't thought much about whether this can be easily done and maybe it's not very useful in the end.

[renatomello]

Thanks @renatomello. Generally fine with me, but I have not checked validity so I just trust the test.

It took me some time to understand the supported input shapes and I think we are kind of overcomplicating it by supporting 1-dimensional arrays. To me, since this is a partial trace, it would even be sufficient to stick to 2-dimensional. If someone wants to process a 1-dimensional one, they can still do the outer product before calling this (this way it is also a bit more modular). However, I am not the best candidate user of this, so it's not a strong opinion.

I think it's fine supporting statevectors because it takes an extra step from the users' hands at the price of a handful of lines of code on our side. So the trade-off is worth IMO.

Other than that, I understand you are also supporting a "batch" dimension (N). There may be a way to generalize this to arbitrary number of batch dimensions ((..., k, k)), so that you don't even have to distinguish between batch/no batch, but I haven't thought much about whether this can be easily done and maybe it's not very useful in the end.

I like the idea, but for the interest of time I prefer to move forward as is because we have some priorities that are more urgent.