You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is an attempt at being more principled about dealing with complex sectorscalartypes with tensors that don't necessarily have complex entries.
In the context of #356 I bumped into a couple of these, so I figure might as well look a bit more carefully at the various occurrences.
My general strategy here is to use TO.tensoralloc_add as much as possible, since we already fixed this issue in that function.
However, I also had to modify compose_dest, since there are no recouplings required there, and therefore there is no need to update the scalartype.
I also added the utility check_spacetype function that does exactly what you suspect it does, and just centralizes various places in the code where this was in use.
Haven't managed to go through this in detail, but I wonder if before trying to fix this and make it consistent, it might be useful to first settle the question if we want to separate between fusionscalartype and braidingscalartype? I think it is a valid request to use e.g. FibonacciAnyon in a context where there will be no braiding (e.g. golden chain), and therefore to only use real numbers.
I think in general I completely agree to introduce these functions and make that distinction.
I'll get started on that, but I don't think it hurts to already merge this since it does fix the problem, albeit not in the most efficient way.
I would in any case much rather have something that too eagerly becomes complex instead of errors out.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is an attempt at being more principled about dealing with complex
sectorscalartypes with tensors that don't necessarily have complex entries.In the context of #356 I bumped into a couple of these, so I figure might as well look a bit more carefully at the various occurrences.
My general strategy here is to use
TO.tensoralloc_addas much as possible, since we already fixed this issue in that function.However, I also had to modify
compose_dest, since there are no recouplings required there, and therefore there is no need to update the scalartype.I also added the utility
check_spacetypefunction that does exactly what you suspect it does, and just centralizes various places in the code where this was in use.