Fix pytorch gradients

[Simone-Bordoni]

Fix #1449

Checklist:

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

[BrunoLiegiBastonLiegi]

I found a potential problem when you cast the parameters of parametrized gates:

qibo/src/qibo/backends/pytorch.py

Line 32 in 1b6eb8a

return self.np.tensor(x, dtype=self.dtype, requires_grad=self.requires_grad)

here you cast to self.dtype which is usually torch.complex128 but it should actually be torch.float32/64 since this is a parameter. I don't know whether this is the origin of the problem with the gradients though.

EDIT: nevermind, you necessarily have to cast to complex otherwise when you build the matrix elements pytorch complains about mismatching dtypes...

[Simone-Bordoni]

I found a potential problem when you cast the parameters of parametrized gates:

qibo/src/qibo/backends/pytorch.py

Line 32 in 1b6eb8a

return self.np.tensor(x, dtype=self.dtype, requires_grad=self.requires_grad)

here you cast to self.dtype which is usually torch.complex128 but it should actually be torch.float32/64 since this is a parameter. I don't know whether this is the origin of the problem with the gradients though.
EDIT: nevermind, you necessarily have to cast to complex otherwise when you build the matrix elements pytorch complains about mismatching dtypes...

Actually this may be part of the problem, i am rewriting in a better way the whole casting function differentiating the matrix_dtype from the parameters_dtype

[Simone-Bordoni]

Now the gradients are passing however their final value is always zero. I have tried visualizing the computational graph (shown below) and all the operations seems to be performed correctly.
I am currently tsting a simple circuit with just one rotation gate (test_torch_gradients.py).
In the next days I will not be able to work furthermore on this issue, I will resume working on the gradients next week. In the meantime if you find any possible reason for this problemlet me know, it would be very helpful.

[Simone-Bordoni]

Now the gradients are passing however their final value is always zero. I have tried visualizing the computational graph (shown below) and all the operations seems to be performed correctly. I am currently tsting a simple circuit with just one rotation gate (test_torch_gradients.py). In the next days I will not be able to work furthermore on this issue, I will resume working on the gradients next week. In the meantime if you find any possible reason for this problemlet me know, it would be very helpful.

Now the gradients are passing however their final value is always zero. I have tried visualizing the computational graph (shown below) and all the operations seems to be performed correctly. I am currently tsting a simple circuit with just one rotation gate (test_torch_gradients.py). In the next days I will not be able to work furthermore on this issue, I will resume working on the gradients next week. In the meantime if you find any possible reason for this problemlet me know, it would be very helpful.

I found out the problem was with the target state. now the gradients are passing correctly,
as soon as possible I will clean up the code and it should be ready for a review.

[Simone-Bordoni]

I think that now everything has been fixed.
The changes required were bigger than expected, I had to add the backend in the gate decompositions and in other parts.
I have added a test to check the correct backpropagation in test_torch_gradients.py so that thay can be easily moved to qiboml.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.93%. Comparing base (36ed3fe) to head (3f22d8d).
Report is 51 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1450      +/-   ##
==========================================
- Coverage   99.93%   99.93%   -0.01%     
==========================================
  Files          81       81              
  Lines       11820    11790      -30     
==========================================
- Hits        11812    11782      -30     
  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]

Thanks @Simone-Bordoni, looks good. The only two things that I am not a fan of are:

• The new requires_grad argument added to cast. I would remove that and, when possible, move the functions, where it is needed, inside the backend as methods (like the _curve_fit case discussed above) . For the cases when it is not possible I would create specific backend.cast_parameter()

# numpy
def cast_parameter(self, x, **kwargs):
    return self.cast(x, **kwargs)
#  torch
def cast_parameter(self, x, **kwargs):
    return self.cast(x, **kwargs).requires_grad_()

• The fact that the decomposition needs the backend now. Ideally, I don't think this should be the case, but I don't know in practice if it's possible to avoid.

[Simone-Bordoni]

Thanks @Simone-Bordoni, looks good. The only two things that I am not a fan of are:

• The new requires_grad argument added to cast. I would remove that and, when possible, move the functions, where it is needed, inside the backend as methods (like the _curve_fit case discussed above) . For the cases when it is not possible I would create specific backend.cast_parameter()

# numpy
def cast_parameter(self, x, **kwargs):
    return self.cast(x, **kwargs)
#  torch
def cast_parameter(self, x, **kwargs):
    return self.cast(x, **kwargs).requires_grad_()

• The fact that the decomposition needs the backend now. Ideally, I don't think this should be the case, but I don't know in practice if it's possible to avoid.

Regarding the decomposition, as it is now you need the backend.
Regarding the cast_parameter, I can add it to the other backends, however the corrections you are suggesting is not possible as the cast_parameter differs a lot from the cast function:

• cast parameter tries to convert integer to float in torch
• the default dtype for cast parameter is torch float64 (self.parameter_dtype), opposite to cast that has complex 128 (self.dtype) that is used on matrices.
• cast makes different operations on torch trying to make it the same as tensorflow, for example regarding lists of arrays.

So I agree on adding a cast parameter function to all backends but this should not be related to the standard cast()

[Simone-Bordoni]

Thanks @Simone-Bordoni, looks good. The only two things that I am not a fan of are:

• The new requires_grad argument added to cast. I would remove that and, when possible, move the functions, where it is needed, inside the backend as methods (like the _curve_fit case discussed above) . For the cases when it is not possible I would create specific backend.cast_parameter()

# numpy
def cast_parameter(self, x, **kwargs):
    return self.cast(x, **kwargs)
#  torch
def cast_parameter(self, x, **kwargs):
    return self.cast(x, **kwargs).requires_grad_()

• The fact that the decomposition needs the backend now. Ideally, I don't think this should be the case, but I don't know in practice if it's possible to avoid.

Regarding the decomposition, as it is now you need the backend.
Regarding the cast_parameter, I can add it to the other backends, however the corrections you are suggesting is not possible as the cast_parameter differs a lot from the cast function:

• cast parameter tries to convert integer to float in torch
• the default dtype for cast parameter is torch float64 (self.parameter_dtype), opposite to cast that has complex 128 (self.dtype) that is used on matrices.
• cast makes different operations on torch trying to make it the same as tensorflow, for example regarding lists of arrays.

So I agree on adding a cast parameter function to all backends but this should not be related to the standard cast()

[Simone-Bordoni]

Regarding the decomposition, as it is now you need the backend. Regarding the cast_parameter, I can add it to the other backends, however the corrections you are suggesting is not possible as the cast_parameter differs a lot from the cast function:

• cast parameter tries to convert integer to float in torch
• the default dtype for cast parameter is torch float64 (self.parameter_dtype), opposite to cast that has complex 128 (self.dtype) that is used on matrices.
• cast makes different operations on torch trying to make it the same as tensorflow, for example regarding lists of arrays.

So I agree on adding a cast parameter function to all backends but this should not be related to the standard cast()

Actually cast_parameter() was made to cast a single parameter for matrix_parametrized().
An idea could be making it a helper method in the torch backend and creating a new public mthod like cast_parameters() to be used in these situations.
Anyway I don't know if @renatomello agrees on adding this new function to the numpy backend to avoid different backend behaviours.