Prevent construction of multifusion tensors with incompatible coloring - #515
Prevent construction of multifusion tensors with incompatible coloring#515borisdevos wants to merge 16 commits into
Conversation
lkdvos
left a comment
There was a problem hiding this comment.
I do think this is probably quite a big performance hit right in the hot path of the fusiontree constructors though, I don't think there is typically a fast implementation of this. Additionally, I was kind of expecting to convert more things to Nsymbol, to actually make them error if the fusion is disallowed?
|
I'm misunderstanding then what kind of behavior we want. So we want |
|
I think that was what I was expecting, especially since we decided |
Codecov Report✅ All modified and coverable lines are covered by tests.
... and 51 files with indirect coverage changes 🚀 New features to boost your workflow:
|
This reverts commit 5f9e5be.
…into bd/fusiontree-iterate
Nsymbol calls or add guards in fusion tree iteration
lkdvos
left a comment
There was a problem hiding this comment.
Other than the comments, looks good, thanks for looking into this!
…into bd/fusiontree-iterate
Deals with #514, at least partially.
Now we have
which behaves the same way as
Edit: decided to actually prevent construction of these kinds of tensors at the level of the product space and hom space.
Since this was incompatible with the previous implementation of
unitspace, this now errors forGenericUnitsector types.