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

Unify (or at least connect) order_hom and rel_hom #5525

Open
awainverse opened this issue Dec 29, 2020 · 1 comment
Open

Unify (or at least connect) order_hom and rel_hom #5525

awainverse opened this issue Dec 29, 2020 · 1 comment

Comments

@awainverse
Copy link
Collaborator

awainverse commented Dec 29, 2020

order_hom is essentially the same as a rel_hom between two instances of .
One of two things should happen:

  • order_hom should be refactored to be based on rel_hom, with an interface to show that this is the same thing as a monotone function
  • An API should be built out for translating between order_homs and rel_homs, enough that it is easy to link order_homs and order_embedding/order_isos.
@YaelDillies YaelDillies changed the title Unify (or at least connect) preorder_hom and rel_hom Unify (or at least connect) order_hom and rel_hom Apr 5, 2022
@YaelDillies
Copy link
Collaborator

Now that I worked a lot on order homs (building the order categories), I feel like the first option is the wrong one. Building on top of rel_hom means that we don't have custom field names and we can't extend order_hom. Instead, we must extend @rel_hom α β (≤) (≤).

I will work on redefining order_embedding and order_iso away from rel_embedding and rel_iso.

I'm not sure we need the second option much either, because rel_homs are used so little in mathlib. But maybe one day we will want to translate between orders and graphs?

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

No branches or pull requests

2 participants