-
Notifications
You must be signed in to change notification settings - Fork 141
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
Path solver #1104
Path solver #1104
Conversation
I just started to look into a solver for wild categories: #1105 |
This groupoid solver is specyficly specialised to paths (it is aware of hcomps - various ways to compose two paths). |
Maybe it is better to call the whole thing path solver instead of groupoid solver? |
I am experimenting but comparing result of apllying this solver for groupoid encoded as HIT vs adapting Group solver, by forcefuly typechecking proofs about groups as prooof about groupoids. Once I have both we may look at the caveats (unless they are obvious already, and someone can help me make a choice). |
for the same problem, terms for paths can be much smaller, but I am noot sure if "whiskering(?)" the proof back to groupoid wont cancel those gains anyway |
I would like to check both aproaches on some computationaly relevant example |
I would expect that the approach from your group solver carried over to groupoids, is a lot more performant. But maybe my intuition is wrong. The idea is, that if you write down something like 'free groupoid on a graph' as some inductive type, then you only have what you actually need - and paths have more stuff in general. |
This is just rought intuition, but I am really curious what will happen: In paths you can do:
we do not need to apply assoc repatedly, |
Idea abowe woudl work really only for univalent groupoids, and will be ineficcient in general (I tested it) |
now it works without asusmptions about hLevel.
I will work to avoid code duplciation with existing tactics before marking it ready for review.