Fix QNSPSA Optimizer

[albi3ro]

Fixes #5437 . [sc-59838]

When we started distinguishing vanilla numpy and autograd numpy in our source code, we accidentally switched to using vanilla numpy in the QNSPSA optimizer instead of autograd numpy. This switches it back.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.67%. Comparing base (1bb10be) to head (efed07b).
Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5439      +/-   ##
==========================================
- Coverage   99.68%   99.67%   -0.01%     
==========================================
  Files         402      402              
  Lines       37534    37251     -283     
==========================================
- Hits        37414    37130     -284     
- Misses        120      121       +1     

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

[isaacdevlugt]

Thanks Christina! The fix works for me.

[PietropaoloFrisoni]

Thanks!

[astralcai]

I have a question: I see that here pennylane.numpy is used in all cases instead of vanilla numpy. Is this fine or should we differentiate based on whether trainability is needed for each particular case?

[albi3ro]

I have a question: I see that here pennylane.numpy is used in all cases instead of vanilla numpy. Is this fine or should we differentiate based on whether trainability is needed for each particular case?

@astralcai Something we could potentially look into. Some of the variables we are creating might not actually end up being trainable, and could just being intermediaries. But the optimizers are autograd-only, so we don't have to worry about mixing ml-framework types. I'm not as concerned about using autograd numpy as I would be in other parts of the code base.