Remove Tensor and Hamiltonian in python frontend for lightning

[lillian542]

We are removing the Tensor and Hamiltonian classes, so we should remove their (minimal) remaining references in the Lightning python code.

Blocks running CI for the PL PR #6548 to remove legacy_opmath, since every test that uses lightning.qubit fails with Tensor removed.

[sc-77523]

[codecov]

Codecov Report

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

Project coverage is 92.14%. Comparing base (4659093) to head (ed37123).
Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
pennylane_lightning/core/lightning_base.py	0.00%	4 Missing ⚠️
pennylane_lightning/core/_measurements_base.py	25.00%	3 Missing ⚠️
pennylane_lightning/core/_serialize.py	75.00%	1 Missing ⚠️

❗ There is a different number of reports uploaded between BASE (4659093) and HEAD (ed37123). Click for more details.

HEAD has 30 uploads less than BASE

Flag	BASE (4659093)	HEAD (ed37123)
	38	8

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #994      +/-   ##
==========================================
- Coverage   98.00%   92.14%   -5.86%     
==========================================
  Files         231      104     -127     
  Lines       36387    16266   -20121     
==========================================
- Hits        35662    14989   -20673     
- Misses        725     1277     +552     

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

[maliasadi]

Awesome! Thanks @lillian542 🥳

[multiphaseCFD]

Thanks @lillian542 . Awesome. Just wondering if same action is required for lightning_tensor?

[lillian542]

@multiphaseCFD thanks, good question! It doesn't import or any custom code for Hamiltonian or Tensor, so I had discounted it, but I went back and checked and "Hamiltonian" was still on the list of supported ops, which it preferably shouldn't be. I've updated that now; as far as I can see, nothing else in the code for that device is specific to the legacy opmath.

[multiphaseCFD]

@multiphaseCFD thanks, good question! It doesn't import or any custom code for Hamiltonian or Tensor, so I had discounted it, but I went back and checked and "Hamiltonian" was still on the list of supported ops, which it preferably shouldn't be. I've updated that now; as far as I can see, nothing else in the code for that device is specific to the legacy opmath.

Thanks @lillian542 . Could you please also add the ci:use-gpu-runner label to this PR and then trigger CIs? Then changed lines in lightning.gpu and lightning.tensor can be tested.

[AmintorDusko]

@maliasadi and @lillian542, we have some C++ tests that emulate the data structure of a Tensor and/or Hamiltonian. Are we renaming, updating or removing these tests? Or are we going to leave it for now?
Lilian, please refresh my mind, what will be substituting these in the new opmath?

[lillian542]

@multiphaseCFD if we need to make changes in the C++ backend, would it be alight for that to happen in a different PR? Since PennyLane runs tests with lightning.qubit, the CI for the PennyLane PR that removes legacy operator arithmetic is blocked by this.

The Tensor class will now be fully replaced by Prod. The default has been Prod for a few months, but we have continued to support Tensor if users opt in.

The Hamiltonian class will now be replaced by LinearCombination and Sum (which one depends on how the user creates the operator). LinearCombination is a subclass of Sum with some minimal, generally user-facing differences. Like with Tensor, this behaviour has been the default for a few months, and only users who 'opted out' of the new behaviour have still been using the legacy opmath support.

[multiphaseCFD]

@multiphaseCFD if we need to make changes in the C++ backend, would it be alight for that to happen in a different PR? Since PennyLane runs tests with lightning.qubit, the CI for the PennyLane PR that removes legacy operator arithmetic is blocked by this.

The Tensor class will now be fully replaced by Prod. The default has been Prod for a few months, but we have continued to support Tensor if users opt in.

The Hamiltonian class will now be replaced by LinearCombination and Sum (which one depends on how the user creates the operator). LinearCombination is a subclass of Sum with some minimal, generally user-facing differences. Like with Tensor, this behaviour has been the default for a few months, and only users who 'opted out' of the new behaviour have still been using the legacy opmath support.

Thanks @lillian542 . Good question. I would suggest to create a new PR to work on the C++ layer changes as long as current changes in the frontend do not break the pipeline. But I would like to ask @maliasadi to decide.

[maliasadi]

we have some C++ tests that emulate the data structure of a Tensor and/or Hamiltonian. Are we renaming, updating or removing these tests? Or are we going to leave it for now?

@AmintorDusko @multiphaseCFD @lillian542 We don't need any changes in C++ right now as Lightning and Catalyst continue serializing qml.pauli.PauliWord --> TensorProduct and qml.pauli.PauliSentence --> Hamiltonian.
We will simplify the observable serialization implementation and extend the implementation of C++ observables to adhere the new PL obs abstractions in both Lightning and Catalyst.

[multiphaseCFD]

Thanks @lillian542 for the nice work! Happy to approve!