| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Codecov Report✅ All modified and coverable lines are covered by tests.
|
Sorry, something went wrong.
| return h | ||
| end | ||
| Base.hash(b::FusionTreeBlock, h::UInt) = hash(fusiontrees(b), h) | ||
| Base.hash(b::FusionTreeBlock, h::UInt) = isempty(b) ? h : hash(b.uncoupled, hash(b.isdual, h)) |
There was a problem hiding this comment.
Is just returning h in the empty case a good idea? Or should we e.g. return the equivalent of an empty tuple, hash((), h) ?
Sorry, something went wrong.
|
Clearly, adding this hash function is a no-brainer. This is really a major oversight. One off-topic question that comes up, thinking about the isempty case. Is it problematic that, if we create a FusionTreeBlock from sectors that don't have a single compatible fusion tree (this must be in the multifusion case), that we cannot recover the sectors and isdual flags? |
Sorry, something went wrong.
Hashing the first tree pair still covers the block's defining data (uncoupled, isdual), but additionally disambiguates the ad-hoc single-pair blocks constructed in planar_trace, which would otherwise all collide in the fstranspose LRU cache. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
That's actually a very good point. I think currently we are guarding most of the code to never enter this part when there are no fusiontrees (these objects are typically generated from indexmanipulation loops, where we know everything has at least one channel, since it is from a valid tensor). This did make me check the codebase, and we do actually have one spot where this can be an issue (properly denoted hack): where we would now end up with colliding hashes because these only have a single fusiontree, so I've reworked the implementation to just hash the first fusiontree pair, which is again a hack but might be worth it to remain like that until I properly fix that "hack" of the traces. (See #522) |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Potential first step to addressing #516.
The cache underlying permutes of AdjointTensorMaps ( GLOBAL_FSBRAID_CACHE) never gets a single hit, making it effectively useless. This cache uses keys generated from a FusionTreeBlock, but Base.hash wasn't defined for this type causing literally all keys to miss. Adding the hash improves the performance of permuting AdjointTensorMaps with non-Abelian sector types.
Running the reproduction script from #516 gives:
Reproduction scriptAfter
Before