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

Free groups #89

Merged
merged 7 commits into from Apr 25, 2018
Merged

Free groups #89

merged 7 commits into from Apr 25, 2018

Conversation

kckennylau
Copy link
Collaborator

Local copy: https://github.com/kckennylau/Lean/blob/master/free_group.lean

Construction given by https://math.stackexchange.com/a/852661/328173

A three-step approach to constructing the free group over a set (type).


end to_inv_type

@[reducible] def word (S : Type u) : Type u :=
Copy link
Member

Choose a reason for hiding this comment

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

Can this not go in the global namespace?

@@ -0,0 +1,360 @@
-- https://math.stackexchange.com/a/852661/328173
Copy link
Member

Choose a reason for hiding this comment

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

Add a header to the file similar to other files in mathlib, with you as the author

@digama0 digama0 force-pushed the master branch 2 times, most recently from 2f0beae to 22e671c Compare April 5, 2018 05:29
@kckennylau kckennylau closed this Apr 5, 2018
@johoelzl
Copy link
Collaborator

johoelzl commented Apr 5, 2018

@kckennylau instead of closing this pull request, can you keep it and just update the branch on your side?

@kckennylau kckennylau deleted the patch-6 branch April 5, 2018 07:53
@kckennylau kckennylau mentioned this pull request Apr 5, 2018
@kckennylau kckennylau restored the patch-6 branch April 5, 2018 08:32
@kckennylau
Copy link
Collaborator Author

oh wait is this a bug

@kckennylau kckennylau reopened this Apr 5, 2018
@johoelzl johoelzl changed the title Create free_group.lean Free groups Apr 5, 2018

universes u v

class inv_mon (M : Type u) extends monoid M, has_inv M :=
Copy link
Collaborator

Choose a reason for hiding this comment

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

inv_mon doesn't seam to be a very informative name, especially since it is a global name I would prefer something longer: monoid_with_involution or monoid_with_inv?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Or involution_monoid, inv_monoid, etc

one_inv := one_inv,
inv_inv := inv_inv }

class inv_mon.is_hom (M : Type u) (N : Type v) [inv_mon M] [inv_mon N] (f : M → N) : Prop :=
Copy link
Collaborator

Choose a reason for hiding this comment

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

Don't we have monoid homomorphisms already?


end inv_mon.to_group

class inv_type (IT : Type u) extends has_inv IT :=
Copy link
Collaborator

Choose a reason for hiding this comment

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

Move this before mon_inv, extend mon_inv using this than to_inv_type is added implicitly and give it another name like: involution?

instance inv_mon.to_inv_type (M : Type u) [inv_mon M] : inv_type M :=
{ inv_inv := inv_mon.inv_inv }

@[reducible] def inv_type.to_inv_mon (IT : Type u) [inv_type IT] :=
Copy link
Collaborator

Choose a reason for hiding this comment

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

I would not introduce an extra name for it. Is there a specific reason why you don't want to use list?

parameters (f : IT → M) -- IT → Forgetful(M)
parameters (Hinv : ∀ x, f x⁻¹ = (f x)⁻¹)

def left_adjoint : inv_type.to_inv_mon IT → M -- Free(IT) → M
Copy link
Collaborator

Choose a reason for hiding this comment

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

Use list.prod?

| [] := 1
| (h::IT) := f h * left_adjoint IT

theorem left_adjoint.mul : ∀ x y, left_adjoint (x * y) = left_adjoint x * left_adjoint y
Copy link
Collaborator

Choose a reason for hiding this comment

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

prod_mul


end inv_type.to_inv_mon

@[reducible] def to_inv_type (T : Type u) :=
Copy link
Collaborator

Choose a reason for hiding this comment

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

I guess α × bool would be a better choice.

namespace to_inv_type

def inv (T : Type u) : to_inv_type T → to_inv_type T
| (sum.inl x) := sum.inr x
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is then just bnot on the second argument

def reduce : word S → word S
| ((sum.inl x)::(sum.inr y)::t) := if x = y then reduce t else ((sum.inl x)::(sum.inr y)::reduce t)
| ((sum.inr x)::(sum.inl y)::t) := if x = y then reduce t else ((sum.inr x)::(sum.inl y)::reduce t)
| (h1::h2::t) := h1::h2::reduce t
Copy link
Collaborator

Choose a reason for hiding this comment

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

This looks wrong to me, shouldn't reduce [a, b, b⁻¹] evaluate to [a]? As far as I see it this is not the case.

variable [decidable_eq S]

def reduce : word S → word S
| ((sum.inl x)::(sum.inr y)::t) := if x = y then reduce t else ((sum.inl x)::(sum.inr y)::reduce t)
Copy link
Collaborator

Choose a reason for hiding this comment

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

If you use bool you can reduce these two cases to one.


namespace free_group

variables (S : Type u)
Copy link
Collaborator

Choose a reason for hiding this comment

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

For consistency, please change your upper case type names to α, β, γ etc.

@johoelzl
Copy link
Collaborator

The new version looks great.

What is the reason why you don't want to use quot on red.step to define free_group? Then the lifting proofs should be easier as there is no transitivity necessary.

@kckennylau
Copy link
Collaborator Author

I find quotient to be more user-friendly than quot, and more mathematical to be honest (I don't remember the last time someone quotiented by a non-transitive relation). However, I'm now experimenting with quot to see how it goes.

@digama0
Copy link
Member

digama0 commented Apr 20, 2018

It's not uncommon to define a quotient by saying what things are related, where implicitly you are supposed to take the equivalence closure of the given relation. That is exactly what quot does, it's not really a quotient by a non-transitive relation so much as a quotient by the equivalence relation generated by a non-transitive relation.

@kckennylau
Copy link
Collaborator Author

Now I'm stuck on proving that "of" is injective. Before I could use quotient.exact.

@johoelzl
Copy link
Collaborator

You can use quot.exact. You will need to prove eqv_gen red.step L₁ L₂ is the same as ∃ L₃, red L₁ L₃ ∧ red L₂ L₃ . But this is essentially what you have in https://github.com/leanprover/mathlib/pull/89/files#diff-5f7e06d86429e56d8e516817d14026d1R131

@kckennylau
Copy link
Collaborator Author

Then I don't see the point of using quot instead of quotient.

@johoelzl
Copy link
Collaborator

The point is that quot.lift on red.step is easier to use than quotient.lift on the setoid.r defined in your file.
When definining mul, inv, etc. one just need to show that your definitions are invariant under exactly one reduction step, and not a sequence of reduction steps.

@kckennylau
Copy link
Collaborator Author

@johoelzl Now that I changed the definition of free group to quot $ @free_group.red.step α, I don't really feel like I have removed a lot of lemmas. For example, consider the lemma red.append that says red commutes with list.append, which was used to prove that multiplication is well-defined. Well, now it is used in reduce.red to show that there is a sequence of reduction from L to reduce L, which is one of the two interface theorems of reduce (the other being reduce.min). By that, I mean that every other theorem of reduce are proved from these two theorems, i.e. they characterise the reduce function.

@digama0
Copy link
Member

digama0 commented Apr 24, 2018

@kckennylau Does this have all your latest work on free groups?

@digama0
Copy link
Member

digama0 commented Apr 24, 2018

Also we need to have @johoelzl and @kckennylau work out the differences in their developments here

@kckennylau
Copy link
Collaborator Author

@digama0 yes.

@johoelzl
Copy link
Collaborator

My idea is to merge this PR and then gradually add my theory on transitive closure etc.

@johoelzl johoelzl merged commit 716decc into leanprover-community:master Apr 25, 2018
@kckennylau kckennylau deleted the patch-6 branch November 16, 2018 11:58
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

Successfully merging this pull request may close these issues.

None yet

3 participants