search

PennyLaneAI / qml

Introductions to key concepts in quantum programming, as well as tutorials and implementations from cutting-edge quantum computing research.
https://pennylane.ai/qml
Apache License 2.0
512 stars 182 forks source link

How to use the new `default.tensor` quantum device #1133

Closed PietropaoloFrisoni closed 1 day ago

PietropaoloFrisoni commented 3 weeks ago

Before submitting

Please complete the following checklist when submitting a PR:

When all the above are checked, delete everything above the dashed line and fill in the pull request template.

Title: How to simulate quantum circuits with tensor networks using DefaultTensor

Summary: This how-to guide shows the first steps to use the new default.tensor device that will be available to users in PennyLane 0.37

Relevant references: To be discussed with reviewer(s)

Possible Drawbacks: None that I can think of, except for package dependencies

Related GitHub Issues: None

Related Shortcut Stories: [sc-65345]

If you are writing a demonstration, please answer these questions to facilitate the marketing process.

github-actions[bot] commented 3 weeks ago

Thank you for opening this pull request.

You can find the built site at this link.

Deployment Info:

Note: It may take several minutes for updates to this pull request to be reflected on the deployed site.

PietropaoloFrisoni commented 3 weeks ago

Thanks @Qottmann. Before addressing each point, I see that you asked to comment on the specified kwargs. I actually did it at first, but then I removed the explanations since this was one of the guidelines:

It shouldn't teach or explain, it should assume the reader already understands what X, Y, and Z are. They just want to see the code to remember how to do it in PL.

I can insert an explanation for each of the keyword arguments I used, but I am not sure if this is the right thing to do in such a short guide

Qottmann commented 3 weeks ago

It shouldn't teach or explain, it should assume the reader already understands what X, Y, and Z are. They just want to see the code to remember how to do it in PL.

I can insert an explanation for each of the keyword arguments I used, but I am not sure if this is the right thing to do in such a short guide

I think the teaching and explaining refers to the underlying theory. I agree that in-depth explanations of tensor network methods are better suited for the upcoming demos on that, but it would still be crucial and valuable to explain the code and in particular what those settings that you set do.

PietropaoloFrisoni commented 3 weeks ago

Thanks for the suggestions @Qottmann, @trbromley, and @josh146 (I tagged you all here even though some of you provided feedback on Slack).

I did my best to find a compromise between all the suggestions you provided. I have addressed each entry individually, so I summarize the general points here.

Regarding the keyword arguments provided, I changed some of them to slightly improve the performance of the circuits (this lowers the total execution time of this guide by about 10 seconds). I have inserted one/two sentences to comment on each choice, referring to the device documentation for further details. I also added a final section of a few sentences and general comments on performance and future developments.

Further, it would be crucial to show a bond dimension scaling in the MPS section. That is, take some circuit expectation value and scale the bond dimension from something small to something large. The expectation value should then converge to the true value once a suitably large circuit is found. With this you can well describe the function of the bond dimension and how to set it.

@Qottmann I really like the idea, but based on all the feedback and guidelines I received it seems to me that this might not be the context. This is definitely something we can insert in the demo on Matrix Product States, and then link the demo to this short how-to guide. As an additional comment, to scale up the maximum bond dimension it would be nice to be able to change execution configuration at runtime (this requirement was eventually removed from this project) so that we don't have to re-instantiate the device every time.

As a final comment, probably the "usage details" section of default.tensor is too detailed compared to all the other devices in PennyLane (most of them don't even have one) and makes this how-to seem almost like a repetition, but it seems to me that this how-to overall reflects the requirements provided. We could think about reducing the "usage details" section of this device, but at this point, I don't think it makes sense (besides, more information is better than less).