Symmetric difference as a quanthash-y op #362
Closed
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.
(^+) -- symmetric difference for quant hashes
I'm still fairly convinced that it makes sense to unify set and quanthash
operators, but this patch is designed to open discussion about 'symmetric
difference' behavior for quanthashes as a separate issue from that. I've
thought about it quite a bit, maybe too much.. Either way, I'm not as sure about it
as when I started.
Outside of LoL context, (^+) makes a fair amount of sense -- give back what was
left after removing any intersecting values:
The implementation uses the absolute value of the subtraction of the
intersecting keys. This allows for symmetry, but because subtraction is not
commutative any claim to symmetry is broken by the order of LoLs.
It could also be argued that the absolute value symmetry is flawed to begin
with, and the ordering should matter in both (^+) and [(^+)] forms.
I'm not as convinced anymore of how important, let alone correct, either approach is,
but I wanted to publish it to see how others might feel. I haven't found spec
information on set operators, but I remember looking when I first started on
this months ago.
(Also, I wanted to note that since starting this work, lizmat++ has contributed a
pretty freaking sweet patch to add LoL to (^). It makes me wonder what might be
possible here, but "implement first, apologize second, golf third" seems like a better
approach for the current tuits.)
CAUTION: NOT WORKING
However, this branch isn't just about that. This works from the repl (but crashes from a file, see the gist linked from the bottom):
But this doesn't.
This gist contains a test file which will fail with the same issue: https://gist.github.com/ab5tract/572342901a4561c53dbc