Skip to content
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

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

EgbertRijke
Copy link
Collaborator

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.

@fredrik-bakke
Copy link
Collaborator

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.

@fredrik-bakke
Copy link
Collaborator

Of course, is-prop-iso will still rely on extensionality principles of the underlying type of morphisms, but many other constructions won't.

Comment on lines +61 to +63
is-iso-Precategory : UU l2
is-iso-Precategory =
section-hom-Precategory C f × retraction-hom-Precategory C f
Copy link
Collaborator

@fredrik-bakke fredrik-bakke Feb 11, 2025

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.

@fredrik-bakke
Copy link
Collaborator

@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.

@fredrik-bakke
Copy link
Collaborator

There's also a question on whether we prefer the terminology section/retraction vs split epi/split mono in category theory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants