-
Notifications
You must be signed in to change notification settings - Fork 73
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
Let being an isomorphism be a property #1071
base: master
Are you sure you want to change the base?
Conversation
Hey! Although I don't know what your precise motivation is, I'm curious wouldn't a better setting be to consider this in a wild category without a class of equivalences? Then the framework will apply to structures that are not set-level, and we will additionally be able to avoid function extensionality (because of the setoid relation). To me, that sounds like a better definition. |
Of course, |
is-iso-Precategory : UU l2 | ||
is-iso-Precategory = | ||
section-hom-Precategory C f × retraction-hom-Precategory C f |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Considering that morphism types in a category are sets, I'd propose we rather use the following definition
Σ ( hom-Precategory C y x)
( λ g →
( comp-hom-Precategory C f g =ⁱ id-hom-Precategory C) ×
( comp-hom-Precategory C g f =ⁱ id-hom-Precategory C))
for isomorphisms, as this type has a strictly involutive inverse operator. In fact, it would be even better to use the pairing trick that Anders showed us (I'm sorry, this means backtracking on my initiative to use the strictly involutive identity type in set-level category theory), as that definition is predicative, something that might be important for large categories. The only caveat being that it only works for set-level things.
@EgbertRijke This PR seems to have been abandoned. Maybe you'd want to open an issue on this question instead? I'd like to have the changes that are not about invertible morphisms in this PR merged if we can, without tackling the problem on how to define isomorphisms. That's for a different refactoring PR. |
There's also a question on whether we prefer the terminology section/retraction vs split epi/split mono in category theory. |
In this pull request I am testing out whether it is sensible to let isomorphisms be a property in a uniformly defined manner across the library.
Note: these changes are so far experimental, and I am unsure at the moment whether I actually want to propose to merge this line of thought.