search

qiboteam / qibotn

The tensor-network translation module for Qibo.
https://qibo.science
Apache License 2.0
5 stars 1 forks source link

Docs #30

Open alecandido opened 7 months ago

alecandido commented 7 months ago

Sphinx documentation is missing.

At the moment, only the README material is provided as user guide. As soon as docs will be available, I'd move even the bulk of it there, and keep in the README just a minimal example, without documenting all the options (i.e. set the backend through Qibo, execute a circuit).

User guide with the description, and exposing benefits and limitations of the available options, will be much appreciated.

liweintu commented 7 months ago

Closing this as completed in PR #35 .

alecandido commented 7 months ago

I would say that PR #35 introduced the bare minimum, and it's not even properly rendering

image

I would keep this to properly review and extend the documentation, possibly beyond what is already in the README (that still contains more info than the docs), and trim the README itself after that.

liweintu commented 7 months ago

Thanks for the checking @alecandido . I remember I saw this rendering issue before, and applied a fix commit to it. But, maybe the commit was not properly picked up, so the issue showed up again.

Anyway, I've started a new PR #44 and fixed the rendering. It's still WIP, and we'll add some reasonably concrete content to make it a basic guide.

liweintu commented 6 months ago

The rendering issue seems to stick around for v0.0.1, as below, under the link to the stable: https://qibo.science/qibotn/stable/getting-started/quickstart.html image

It is fixed though in v0.0.2, as below, under the link to the latest: https://qibo.science/qibotn/latest/getting-started/quickstart.html image

To avoid this rendering issue, is re-direct to the latest of QiboTN possible from the Qibo docs entry point?

alecandido commented 6 months ago

I believe that it is just an interesting instance of a bug in the docs workflow (still unknown). It will fix on its own after merging/releasing something else, no need to rush for a dedicated fix.

It is interesting because it is showing up in the first release, so, essentially, it is retaining a previous state of latest, instead of the previous stable. This gives us some more info about the bug... However, I still believe I have to rework the stable/latest mechanism. It's not urgent, but I will do (after worfklows@v2).

liweintu commented 6 months ago

I believe that it is just an interesting instance of a bug in the docs workflow (still unknown). It will fix on its own after merging/releasing something else, no need to rush for a dedicated fix.

It is interesting because it is showing up in the first release, so, essentially, it is retaining a previous state of latest, instead of the previous stable. This gives us some more info about the bug... However, I still believe I have to rework the stable/latest mechanism. It's not urgent, but I will do (after worfklows@v2).

Thanks @alecandido for the insight.

The fact that merging/releasing something will fix on its own hints to me that the if branch controlling updates to main is working fine, but the if branch related to tag might have missed something. Maybe that's why tag 0.0.1 didn't capture the document generated after the rendering issue being fixed. In other words, some step for 0.0.1 should've been triggered, but it was not.

alecandido commented 6 months ago

The fact that merging/releasing something will fix on its own hints to me that the if branch controlling updates to main is working fine, but the if branch related to tag might have missed something. Maybe that's why tag 0.0.1 didn't capture the document generated after the rendering issue being fixed. In other words, some step for 0.0.1 should've been triggered, but it was not.

It's more complicated than that. Usually, if you go in the artifact that is generated by the workflow, and check the docs, they are the correct ones (both stable and latest, according to the reference you're looking at). If you then go online, it is not.

NithyasriVS commented 6 months ago

As a continuation to #51, I've proposed a PR #57 to add a note about valid computation settings for QuimbBackend.

The error in #51 is due to setting every possible computation setting to False. For useful computation, one of MPS or expectation should be enabled. In order to use the quimb backend's dense vector function, MPS_enabled must be True since the function uses mps_opts for its calculation. I've proposed a PR to add a note for the user in the doc to let them know that this would be an invalid configuration for computation settings #57

Additionally, error handling can be introduced under quimb.py as follows:

mps_enabled_value = runcard.get("MPS_enabled") expectation_enabled_value = runcard.get("expectation_enabled") if mps_enabled_value == False and expectation_enabled_value == False: raise TypeError("Please set either MPS_enabled or expectation_enabled to True")