Skip to content

Some preparatory proofs for proving sorting+permutation is equality #2724 #2725

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

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

MatthewDaggitt
Copy link
Contributor

I've been sniped by #2723. This is a preparatory PR for the full proof that sorting two lists that are permutations of each other result in equal lists.

@MatthewDaggitt MatthewDaggitt added this to the v2.3 milestone Jun 2, 2025
-- Takes a permutation m → n and creates a permutation
-- suc (suc m) → suc (suc n) by mapping 0 to 1 and 1 to 0 and
-- then applying the input permutation to everything else
swap : Permutation m n Permutation (suc (suc m)) (suc (suc n))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a special case of \oplus of two permutations.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree (lift0 should be as well!), but we don't have such an operation in the library. I have added a note that we should refactor it when we add that operator.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have it buried in my Rig Categories repo. I need to port the basic operations on permutations over. I've got the full semiring defined there.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But also: Function.Related.TypeIsomorphisms etc. as per #2489 ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Plus, of course: we only need this operation because Permutation.Setoid stipulates swap as a constructor... ;-)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, absolutely, there is some great stuff in Function.Related.TypeIsomorphism. And a rather apt 'of course'.

@jamesmckinna
Copy link
Contributor

jamesmckinna commented Jun 5, 2025

Having looked at this, and its followup, in particular lemma ↗↭↗⇒≤, do I understand correctly that the gist of argument is (Cantor-Schroeder-Bernstein redux):

  • Sorted O xs implies that lookup : Fin (length xs) → O.Carrier is an order monomorphism, so has a monotonic inverse on its range
  • for Sorted O xs, Sorted O ys, xs ↭ ys via onIndices thus induces an order isomorphism between Fin n and itself, which is then necessarily the identity
  • thus the O-monotone map from xs to ys induced via conjugation with lookup and its inverse, is also the identity (via faithfulness of the functor induced by onIndices?)
  • hence xs ≋ ys...

If so, then I think this PR and its followup may be simplifiable via the already existing Data.Fin.Properties.injective⇒≤ (and/or pigeonhole/cantor-schroeder-bernstein)?

Copy link
Contributor

@jamesmckinna jamesmckinna left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some nitpicks.
Happy to approve, but I too have been sniped by this... would love to be able to simplify if at all possible!

Comment on lines +288 to +292
_≰_ : {n} Rel (Fin n) 0ℓ
i ≰ j = ¬ (i ≤ j)

_≮_ : {n} Rel (Fin n) 0ℓ
i ≮ j = ¬ (i < j)
Copy link
Contributor

@jamesmckinna jamesmckinna Jun 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we define these here, or have them created automatically by (defining and then) opening the corresponding bundle(s) in Data.Fin.Properties? cf. #2391 / #2490

xs↭ys⇒|xs|≡|ys| : ∀ {xs ys} → xs ↭ ys → length xs ≡ length ys
xs↭ys⇒|xs|≡|ys| (refl eq) = Pointwise.Pointwise-length eq
xs↭ys⇒|xs|≡|ys| (prep eq xs↭ys) = ≡.cong suc (xs↭ys⇒|xs|≡|ys| xs↭ys)
xs↭ys⇒|xs|≡|ys| (swap eq₁ eq₂ xs↭ys) = ≡.cong (λ x → suc (suc x)) (xs↭ys⇒|xs|≡|ys| xs↭ys)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about

Suggested change
xs↭ys⇒|xs|≡|ys| (swap eq₁ eq₂ xs↭ys) = ≡.cong (λ x suc (suc x)) (xs↭ys⇒|xs|≡|ys| xs↭ys)
xs↭ys⇒|xs|≡|ys| (swap eq₁ eq₂ xs↭ys) = ≡.cong 2+_ (xs↭ys⇒|xs|≡|ys| xs↭ys)

(possibly at the cost of an additional import from Data.Nat.Base)?

Comment on lines +240 to +241
_≰_ : ∀ {n} → Rel (Fin n) 0ℓ
_≮_ : ∀ {n} → Rel (Fin n) 0ℓ
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we, by convention, avoid writing the ∀ {n} → prefix here?

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.

4 participants