Interface to "high-level" API (State, NetworkOperator and Expectation)

[yapolyak]

Description

Implemented interface to cutensornet "high-level API", specifically to State, NetworkOperator and Expectation. Mostly based on examples such as this one, but with some bugs fixed and some uncovered features discussed here and here with cuTN authors.

Note that automatic parallelisation (while not available in their examples yet) should be straightforward to achieve.

This shoud be wrapped in a pytket Backend class in a future PR.
I also suppose that Marginal, Accessor and Sampler objects deserve to be interfaced to in the future.

Related issues

NA

Checklist

• I have run the tests on a device with a GPU.
• I have performed a self-review of my code.
• I have commented hard-to-understand parts of my code.
• I have made corresponding changes to the public API documentation.
• I have added tests that prove my fix is effective or that my feature works.
• I have updated the changelog with any user-facing changes.

[PabloAndresCQ]

An upcoming PR will need to reintroduce the ability to use mutable tensors. To do so in ExpectationValue, the user will need to have access to an ExpectationValue object that they keep alive and update by calling the appropriate update_tensors method. The API will need to change accordingly and either provide a shallow wrapper of NVIDIA's ExpectationValue object, or inform the user to make use of NVIDIA's API explicitly.

I propose we merge this PR now and defer these changes to a later PR once NVIDIA releases their new API (excepted sometime in July), since it's likely they'll be making the user experience smoother on their side, and hence the option of not wrapping ExpectationValue being more reasonable.

[jake-arkinstall]

The changes to the interface are clear, well documented, and I have no criticisms. Tests pass fine, including when merged with the nix-support branch.

On a pedantic level, some of the changes in this commit introduced inconsistent line endings. Most of the files use unix \n line endings, whereas some files now contain \r\n. This isn't a major concern but, for consistency, I recommend that we fix the symptoms and causes before a release is made.

Additionally, I think that some tests need looking at as a pre-release measure. For instance, on the nix-support branch some (existing) tests fail due to the fidelity being better than anticipated, likely due to an updated dependency somewhere along the lines. Adding lower bounds rather than approximations may be better,. Even better would be to move fidelity checks into a benchmarking approach rather than an assertion approach, so we can track improvements and have alerts when there are changes.

[PabloAndresCQ]

Thanks Jake!

Let's add the changes you suggest as a commit before release, once these PRs are merged.

• Regarding line endings we should enforce them in CI or pre-commits somehow (so that they are replaced automatically). I don't have a preference of which of the two to enforce.
• Regarding tests, I agree the test should only be concerned with whether the algorithm works qualitatively as expected, so that it only fails when a change broke the algorithm. Setting a lower bound could work, but then it'd be missing the sublety that these are not exact simulations. For instance, a change could get rid of the way self.fidelity is updated, so that 1.0 is always reported, when it's not the true fidelity. Detecting such a bug would be challenging, but perhaps a fair compromise is to have two asserts: one with a lower bound and another one imposing that fidelity < 1.0. The framework for benchmarking is not a priority atm.

Feel free to create an issue for these in the repo.

[yapolyak]

Thank you guys! Sorry I didn't review it in time, but you seem to be handling it well!