-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docs additions related to constructing a given symmetric TensorMap
#105
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #105 +/- ##
=======================================
Coverage 81.40% 81.40%
=======================================
Files 42 42
Lines 5565 5565
=======================================
Hits 4530 4530
Misses 1035 1035 ☔ View full report in Codecov by Sentry. |
Thanks; this looks great. I've added only a few minor comments. |
I think everything is addressed now, shall I merge? |
Yes, I had planned to do this yesterday but wanted to check with Lander whether this was ready and then somehow forgot. |
Some docs additions that should make it easier for users to find out how to construct symmetric
TensorMap
s corresponding to specific physical systems. In summary I:FusionTree
type, since these need to be accessed explicitly when assigning data slices labeled by splitting-fusion-tree pairs.fusiontrees
iterator generator, both in lib/sectors and lib/tensors.Sector
subtypes, since again these need to be accessed explicitly when assigning data slices.FermionNumber
andFermionSpin
.TensorMap
constructors to lib/tensors.getindex
andsetindex!
forTensorMap
s in lib/tensors.TensorMap
, both by usingblock(::TensorMap, ::Sector)
to assign the full matrix blocks, and using thesetindex!
syntaxt[f₁::FusionTree, f₂::FusionTree] = v
to assign slices oft
labeled by splitting-fusion-tree pairs(f₁, f₂)
.The changes to man/tensors might make it a bit physics-oriented, but since this example was already being used I didn't see much harm in making it more explicit like this. I anyway wouldn't know how to explain the splitting-fusion-tree slice assignment in any other way.