Conversation
| When computing multiple operators on the same state, reuse the belief propagation cache | ||
| to avoid redundant work: | ||
|
|
||
| ```julia | ||
| using ITensors: Op | ||
| sz = expect(psi, Op("Sz", v)) # single-operator form | ||
| ``` |
There was a problem hiding this comment.
The test mentions reusing the BP cache, but the code doesn't show that. Also, I'm not sure if we should be showing Op here, that seems a bit low-level. Maybe best to delete this part and rethink it?
docs/src/computing_properties.md
Outdated
| sz = expect(psi, "Sz") | ||
|
|
||
| # Selected vertices only | ||
| sz = expect(psi, "Sz", [(1,), (3,), (5,)]) |
There was a problem hiding this comment.
This passes vertices as arguments while below it passes them as keyword arguments, better to be consistent. I don't remember what the intended preferred syntax was.
docs/src/solvers.md
Outdated
| nsweeps = 10, | ||
| nsites = 2, | ||
| factorize_kwargs = (; cutoff = 1e-10, maxdim = 50), | ||
| outputlevel = 1, |
There was a problem hiding this comment.
Not a big deal, but I personally don't like this formatting where the = are aligned across lines.
| psi = orthogonalize(psi, [v1, v2]) # two-site center (for nsites=2 sweeps) | ||
|
|
||
| ortho_region(psi) # query current ortho region (returns an index set) | ||
| psi = set_ortho_region(psi, vs) # update metadata only, no tensor operations |
There was a problem hiding this comment.
Maybe we shouldn't document this since it is really more of an internal/expert function (users should generally be orthogonalizing).
| ```@docs; canonical=false | ||
| ITensorNetworks.orthogonalize | ||
| ITensorNetworks.ortho_region | ||
| ITensorNetworks.set_ortho_region |
It would be nice to set it up so that examples interspersed in the docs are run during CI and we get some indication that they at least run without erroring. I think the minimal change to make to achieve that would be to change over the (Note that you can do fancier things where you turn them into proper tests where you check the output: https://documenter.juliadocs.org/stable/man/doctests but we don't have to do that here, just pointing it out for future reference.)
Since it plays an important role in the existing form of the library it seems reasonable to document it. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #300 +/- ##
==========================================
+ Coverage 69.07% 71.50% +2.43%
==========================================
Files 81 81
Lines 4029 4029
==========================================
+ Hits 2783 2881 +98
+ Misses 1246 1148 -98
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@emstoudenmire I changed over most docstrings to regular comments so the API Reference list is much smaller. We can add them back as needed. |
2 participants
This PR adds docstrings to many user-facing functions and create a Documenter setup plus additional Documenter content.
All content (docstrings and Documenter pages) have been manually checked, and I ran and tested the example codes appearing in the Documenter. I created a file test/test_documentation_examples.jl for this purpose.
One question is whether there should be a whole page on the TreeTensorNetwork type, or whether we should somewhat de-emphasize that type. I think it might be better to leave it clearer for someone who is trying to understand the structure of the code and who might occasionally see issues where one needs to convert to the ITensorNetwork type, and so must appreciate that it is a different type.