-
Notifications
You must be signed in to change notification settings - Fork 1
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
Finish proving braid-transpos (in Level0) #52
Comments
I'm going to guess that it is, but that one needs to first shuffle things into place. Our combinators might be 'wrong-handed' (syntactically), but a combination of what is there imply what is needed. |
It might be an application of two hexagons like this. |
That would be rather sneaky, wouldn't it? Hmm, I'm not quite seeing the relation between the two diagrams though. What I'm seeing on the left reminds me of some quantum circuit equivalences that are only true when the X exists, but not derivable otherwise. We can just add a I'm guessing that you have more in your head than what you're communicating here, so that I'm not quite able to bridge the gap. [And I have not had a chance to play with it yet, it might be obvious if I did. But not today, unfortunately.] |
Ah indeed. Very helpful. I was going to look at some of the proofs of Maclane's coherence theorem - I think Dybjer's paper might skip fewer details. If only I could remember the title of that paper! |
Might be this paper? This is only monoidal though. |
Aha - https://www.researchgate.net/publication/227308222_Extracting_a_proof_of_coherence_for_monoidal_categories_from_a_proof_of_normalization_for_monoids . Also, there might be useful material in this nLab page |
I've spent multiple hours, using pen and paper, to scribble many many things, to no avail. I've tried from both ends of what is being asked, and nothing goes. I mean, lots and lots of rewrites are possible, but none of them make things get any closer. In particular, in the hole, and derived things from that, there is nothing quite like that diagram (i.e. the outer edge compositions). The issue seems to be that the ' . 1' on the right in the above (which is + Id in our case) just isn't there in what we're asked to prove by Agda. |
Hmm, I've had a couple more ideas of things to try. One weird thing some of the coherence proofs do (for the pure monoidal case) is to introduce some unitors "in the middle", only to eliminate them later. I had definitely not done that. Plus I've spotted a use of the pentagon equation that I had not considered in that shape. Maybe what I first need to do is to prove the above 'last step' formally, as a warm-up. |
Not sure if it helps, but we found this diagram in Joyal&Street paper: |
It surprisingly doesn't - I had re-derived that one multiple times while noodling around. The problem is the 'outer' (Id +). (Id + swap) is great, (Id + c) for c some non-trivial combinator expression, not so much. I'm starting to wonder if the problem might be that the proof at the lower-level is the problem. I wouldn't think that it's wrong, just that it is not coherently chosen to fit with the rest. I suspect that it is too specialized to the case of having |
So if I'm reading the diffs properly, in the new encoding |
I think there have been many changes since this diff. We're now working with an indexed version of the syntax (indexed by the cardinality), and further we've defined |
More precisely, I believe it got shifted there: 2DTypes/Pi+/Indexed/Equiv2Hat.agda Line 114 in dc31270
|
I had indeed noticed that there had been very major changes. But, as a now completely outside onlooker, I'm still quite interested in trying to understand. And it didn't seem like this obligation would disappear - and indeed it has not, just moved. Indexing by the cardinality is indeed a nice idea. I guess since you're using HoTT, you have use just one and a bunch of transports to tweaks the types. [If you use 2, no transports are needed at all, which I personally find more appealing.] |
Ah you’re saying we should try to index by two numbers… we’ve been having problems with transports. Vikraman and Jacek, is that worth trying or are we too far along the other path :-) ? —Amr
On Mar 12, 2021, at 17:11, Jacques Carette ***@***.******@***.***>> wrote:
I had indeed noticed that there had been very major changes. But, as a now completely outside onlooker, I'm still quite interested in trying to understand. And it didn't seem like this obligation would disappear - and indeed it has not, just moved.
Indexing by the cardinality is indeed a nice idea. I guess since you're using HoTT, you have use just one and a bunch of transports to tweaks the types. [If you use 2, no transports are needed at all, which I personally find more appealing.]
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#52 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAWVV2NEUPARA6CZVRI4UTLTDJ7RTANCNFSM4WR6BE2Q>.
|
Not sure if I follow, types are indexed by one number, combinators are indexed by two numbers. The transport appears when moving from combinators to words in Sn, we have to pick a natural number, so we use a helper lemma to say that |
I think it is now conventional wisdom that permutations (at least in dependent type circles) is an isomorphism between (Just saw @vikraman 's reply as I was typing). Indeed, at the point where you go to Sn, you need transport, it is inevitable. |
Yes, this injectivity of Lines 99 to 124 in dc31270
But there is some Agda hacking necessary in between to make the cardinalities match up. |
It looks like a hexagon but it doesn't match any existing pi combinators?
The text was updated successfully, but these errors were encountered: