Document interface of library#346
Conversation
…recated will be considered internal.)
|
Your PR no longer requires formatting changes. Thank you for your contribution! |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #346 +/- ##
=======================================
Coverage 73.26% 73.26%
=======================================
Files 66 66
Lines 3183 3183
=======================================
Hits 2332 2332
Misses 851 851
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 can you bump the version, fix the docs build, and format just so we can get tests passing? Also, I noticed you are just including the function signatures in the docs. For functions that have docstrings, can you insert the docstring instead of just putting the function signature? |
| * Copy constructor (`itensornetwork.jl`): | ||
| ```julia | ||
| ITensorNetwork{V}(tn::ITensorNetwork) | ||
| ``` | ||
|
|
||
| * From vertex-tensor pairings (`itensornetwork.jl`): | ||
| ```julia | ||
| # Dictionary of vertices => tensors | ||
| ITensorNetwork(ts::AbstractDictionary{<:Any, ITensor}) | ||
| ITensorNetwork(ts::AbstractDict{<:Any, ITensor}) | ||
|
|
||
| # Vector of `vertex => ITensor` pairs | ||
| ITensorNetwork(ts::AbstractVector{<:Pair{<:Any, ITensor}}) | ||
|
|
||
| # Vector of vertices, vector of ITensors | ||
| ITensorNetwork(vertices::AbstractVector, tensors::AbstractVector{ITensor}) | ||
| ``` | ||
|
|
||
| * From a collection of ITensorNetworks. Merges (Kronecker or tensor product) of input networks (`itensornetwork.jl`): | ||
| ```julia | ||
| ITensorNetwork(itns::Vector{ITensorNetwork}) | ||
| ``` | ||
|
|
||
| * From a vector of `ITensor`s, with vertex labels auto-assigned to `eachindex(ts)`. | ||
| Edges are inferred from shared indices (`itensornetwork.jl`): | ||
| ```julia | ||
| ITensorNetwork(ts::AbstractVector{ITensor}) | ||
| ``` |
There was a problem hiding this comment.
I think we can compress this down:
# `keys(tensors)` are vertices, `values(tensors)` are tensors on those vertices
ITensorNetwork(tensors)
ITensorNetwork{V}(tensors)
# Collection of vertices, collection of tensors
ITensorNetwork(vertices, tensors)
ITensorNetwork{V}(vertices, tensors)That actually encompasses all of them (potentially even ITensorNetwork{V}(tn::ITensorNetwork), since keys(tn) should be the vertices and values(tn) should be the tensors, though we'd have to double check if that would work in practice).
Also, I don't particularly like the ITensorNetwork(itns::Vector{ITensorNetwork}) since it doesn't fit into that generic framework very well, I think we should move that to "deprecated".
Note that this doesn't necessarily fully reflect the current state of the code: the constructors are not that generic, some of the ones I wrote above may not exist yet, etc. However, I think for these docs we can do some mixture of summarizing the current code and resummarizing in a way we want the code to be (though please write a comment when these docs diverge from the current code, indicating that they reflect plans for the code).
There was a problem hiding this comment.
Interesting point. Just made this change and I like the idea of the docs being slightly "aspirational" so we can keep working the code toward the docs.
About the last constructor above, though, the ITensorNetwork(ts::AbstractVector{ITensor}) one. That doesn't seem to quite fit either description. I guess keep it as a separate item?
There was a problem hiding this comment.
That's encompassed by ITensorNetwork(tensors), keys(::AbstractVector) and values(::AbstractVector) are defined as we would want them to be for this design:
julia> keys(["x", "y", "z"])
3-element LinearIndices{1, Tuple{Base.OneTo{Int64}}}:
1
2
3
julia> values(["x", "y", "z"])
3-element Vector{String}:
"x"
"y"
"z"
|
By the way, the interface page has gotten quite small... It's nice to see. Once we can build the main features back on top (assuming they aren't already) , such as BP, constructor codes (e.g. fermionic states) based on BP, and solvers, that will be a good situation. |
3 participants
This PR adds documentation of which methods we may consider "interface", and thus should keep and add docstrings for, versus deprecated methods we may want to delete. Methods not in the two files
interface_methods.mdanddeprecated_methods.mdare considered internal, developer-facing methods.