[WIP] New Design #8
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,3 +1,4 @@ | ||
| *.olean | ||
| /_target | ||
| /leanpkg.path | ||
| src/geometric_algebra/experiment/ |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,168 @@ | ||
| # Rethinking the Design of Mathematical Theory Development in Lean | ||
|
|
||
| It turns out that we must have a design template in mind in order to carry on further designing of GA in Lean. This document will address this issue. | ||
|
|
||
| ## Key Insight from Euclidean Geometry | ||
|
|
||
| Taking a step back, let's go back to geometry and look at https://github.com/vaibhavkarve/leanteach2020/blob/master/src/euclid.lean . | ||
|
|
||
| What's a point? How do we tell this concept to the computer? Do we draw a point? Or do we went to analytic geometry and give it a coordinate? It turns out we don't need to do either, the former is infeasible and the latter is the worst idea in formalizing. | ||
|
|
||
| ```lean | ||
| constant Point : Type | ||
| ``` | ||
|
|
||
| How about a line? Same. | ||
|
|
||
| ```lean | ||
| constant Line : Type | ||
| ``` | ||
|
|
||
| How about the relations between points and lines? | ||
|
|
||
| ```lean | ||
| constant lies_on : Point → Line → Prop | ||
| constant between : Point → Point → Point → Prop -- (between a b c) means "b is in between a and c" | ||
| constant congruent {A : Type} : A → A → Prop | ||
| constant distance : Point → Point → ℝ | ||
| ``` | ||
|
|
||
| How about axioms? | ||
|
|
||
| ```lean | ||
| axiom distance_not_neg {p1 p2 : Point} : 0 ≤ distance p1 p2 | ||
| axiom distance_pos {p1 p2 : Point} : p1 ≠ p2 ↔ 0 < distance p1 p2 | ||
| ``` | ||
|
|
||
| And this keeps on and on. Then we have a lot of lemmas and theorems and we still don't need to know what exactly a point is, we don't even need to know how to compute a distance. | ||
|
|
||
| That's it. We don't need concrete types or computibility to reason about them. The semantic can end with their names and we don't need to know more underneath. | ||
|
|
||
| This is the key insight one must have before formalizing a piece of mathematics. | ||
|
|
||
|
There was a problem hiding this comment. TODO: Add structure v.s. class here |
||
| ## Compatibility with mathlib | ||
|
|
||
| A geometric product "contains" an inner product and an exterior product (or wedge product). | ||
|
|
||
| They're established mathematic. There's already inner product space in mathlib and there would definitely be Grassmann Algebra in mathlib one day. And obviously we can't escape the general Clifford Algebra too. | ||
|
|
||
| We must maintain compatibility with them, at least don't conflict with their existence. | ||
|
|
||
| It's not a duplication. The development of mathlib is driven by professional mathematitians, they struggle for math generity but we're working at an abstraction level close to applications. | ||
|
|
||
| We want to stand on such shoulders but we want good capsulation so that we don't want to worry about more abstract concepts and some too general cases. This would definitely leak, it might not be obvious in definitions but it would be very clear when you're proving something. For example, you have to deal with lattice and finsupp when proving things about linear algebra, and that should not be. | ||
|
|
||
| ## Operators | ||
|
|
||
| We start with has_* that have absolutely no axioms with them, they don't have any properties and any behaviors. It's almost just a name. And we associate notations with them. | ||
|
|
||
| Just like in https://github.com/leanprover-community/lean/blob/master/library/init/core.lean#L321 | ||
|
|
||
| ```lean | ||
| class has_mul (α : Type u) := (mul : α → α → α) | ||
| ``` | ||
|
|
||
| we could just: | ||
|
|
||
| ```lean | ||
| class has_wedge (α : Type u) := (wedge : α → α → α) | ||
| class has_inner (α : Type u) := (inner : α → α → α) | ||
|
There was a problem hiding this comment.
|
||
| ``` | ||
|
|
||
| The latter presumably is already in mathlib and has a lot of structures and properties associated with it. We'll deal with that later. | ||
|
|
||
| As for geometric product, I'm thinking about the following short name instead of `geomprod`, `gp` etc.: | ||
|
There was a problem hiding this comment. It turns out that There was a problem hiding this comment. Can't we have There was a problem hiding this comment. old structure is flat, so no matter where smul comes from, as long as it's in our inheritance hierarchy, it conflicts. Better avoid it anyway. |
||
|
|
||
| ```lean | ||
| class has_gmul (α : Type u) := (gmul : α → α → α) | ||
| ``` | ||
|
|
||
| ## Notations | ||
|
|
||
| Now we assoc notations with them: | ||
|
|
||
| ```lean | ||
| -- \circ | ||
| infix ∘ := has_gmul.gmul | ||
| -- \wedge | ||
| infix ∧ := has_wedge.wedge | ||
| -- \cdot | ||
| infix ⋅ := has_inner.inner | ||
| ``` | ||
|
|
||
| We'll always use `local` notations waiting for to be `open_locale`ed. I expect conflicts with notations in mathlib and using this to avoid the conflicts as long as possible. | ||
|
|
||
| > TODO: describe how to use them even when there's a confliction. | ||
|
|
||
| ## Defining without defining | ||
|
|
||
| There're really millions of products defined in GA and they're based on the geometric product. But the definition might not be the most efficient one or the most intuitive one. | ||
|
|
||
| So instead of using `def`, we should make these products just a product with a `Prop` asserting that they're equal to the definition based on gp and let the implementation prove it when intantiate the instance. | ||
|
|
||
| ```lean | ||
| class has_ga_wedge (α : Type u) extends has_wedge := | ||
| (defeq : ∀ a b : α, a ∧ b = (a ∘ b - b ∘ a) / 2) | ||
| ``` | ||
|
|
||
|
|
||
| The above ignore the fact this only works on vectors instead of multivectors. | ||
|
|
||
| So the true story is that we should define `has_sym_mul` and `has_asym_mul` first. | ||
|
|
||
| ## The complication with mul | ||
|
|
||
| mul group diamond | ||
|
|
||
| C wrong | ||
|
|
||
| ## ga extends has_gmul | ||
|
|
||
| ## ga vs mv | ||
|
|
||
| ## the standard template | ||
|
|
||
| import universe open variables | ||
|
|
||
| class with parameter | ||
|
|
||
| bundle | ||
|
|
||
| prio | ||
|
|
||
| marker forgetful_to | ||
|
|
||
| directory structure | ||
|
|
||
| ## defs and lemmas | ||
|
|
||
| contains no lemma except for ... see groups/defs.lean | ||
|
|
||
| recover the usual for demo but never use them | ||
|
|
||
| ## R V are not G0 G1 | ||
|
|
||
| ## G is vector space | ||
|
|
||
| ## linear map | ||
|
|
||
| no `:G` or `coe` | ||
|
|
||
| ## vector_contractible | ||
|
|
||
| non-metric | ||
|
|
||
| quadratic form? | ||
|
|
||
| functional? | ||
|
|
||
| induced topology | ||
|
|
||
| ## attr | ||
|
|
||
| ## universal algebra | ||
|
|
||
| ## what to inherit and forget? | ||
|
|
||
| ## Clifford and Grassmann | ||
|
|
||
| ## graded comes later | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,8 +1,8 @@ | ||
| [package] | ||
| name = "lean-ga" | ||
| version = "0.1" | ||
| lean_version = "leanprover-community/lean:3.17.1" | ||
| path = "src" | ||
|
|
||
| [dependencies] | ||
| mathlib = {git = "https://github.com/leanprover-community/mathlib", rev = "0322d8927d4cdc401a33743ab84e497e85916886"} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,97 @@ | ||
| /- | ||
| Copyright (c) 2020 lean-ga Team. All rights reserved. | ||
| Released under MIT license as described in the file LICENRE. | ||
| Authors: Utensil Rong | ||
| -/ | ||
| import ring_theory.algebra | ||
| import linear_algebra.quadratic_form | ||
| import tactic | ||
| import tactic.lint | ||
|
|
||
| -- import geometric_algebra.generic.operators | ||
|
|
||
| universes u₀ u₁ u₂ | ||
|
|
||
| section prio | ||
| -- set_option default_priority 200 -- see Note [default priority] | ||
| set_option default_priority 100 | ||
|
|
||
| /-- | ||
| -/ | ||
| @[ancestor algebra] | ||
| class semi_geometric_algebra | ||
| (R : Type u₀) [field R] | ||
| (G : Type u₂) [ring G] | ||
| extends algebra R G | ||
| := | ||
| (V : Type u₁) | ||
| [V_acg : add_comm_group V] | ||
| [V_vs : vector_space R V] | ||
|
|
||
| /-- | ||
| -/ | ||
| class weak_geometric_algebra | ||
| (R : Type u₀) [field R] | ||
| (G : Type u₂) [ring G] | ||
| extends semi_geometric_algebra R G | ||
| := | ||
| (fᵣ : R →+* G := algebra_map R G) | ||
| (fᵥ : V →ₗ[R] G) | ||
| -- this is the weaker form of the contraction rule for vectors | ||
| (vector_contract' : ∀ v, ∃ r, fᵥ v * fᵥ v = fᵣ r ) | ||
|
|
||
| /-- | ||
| -/ | ||
| class geometric_algebra | ||
| (R : Type u₀) [field R] | ||
| (G : Type u₂) [ring G] | ||
| extends weak_geometric_algebra R G | ||
| := | ||
| (q : quadratic_form R V) | ||
| (vector_contract : ∀ v, fᵥ v * fᵥ v = fᵣ (q v) ) | ||
|
|
||
| end prio | ||
|
|
||
| -- #print geometric_algebra | ||
|
|
||
| namespace geometric_algebra | ||
|
|
||
| variables {R : Type u₀} [field R] | ||
| -- variables {V : Type u₁} [add_comm_group V] [vector_space R V] | ||
| variables {G : Type u₂} [ring G] | ||
| variables [geometric_algebra R G] | ||
| variables (g : geometric_algebra R G) | ||
|
|
||
| namespace trivial | ||
|
|
||
| lemma assoc : ∀ A B C : G, (A * B) * C = A * (B * C) := mul_assoc | ||
|
|
||
| lemma left_distrib : ∀ A B C : G, A * (B + C) = (A * B) + (A * C) := mul_add | ||
|
|
||
| lemma right_distrib : ∀ A B C : G, (A + B) * C = (A * C) + (B * C) := add_mul | ||
|
|
||
| end trivial | ||
|
|
||
| -- def half : G := fᵣ V (2⁻¹ : R) | ||
|
|
||
| -- local notation ` ½[` T `]` := geometric_algebra.fᵣ (2⁻¹ : T) | ||
|
|
||
| -- def symm_prod (A B : G) : G := ½[R] * (A * B + B * A) | ||
|
|
||
| -- #check symm_prod | ||
|
|
||
| -- instance : inhabited (geometric_algebra R V G) := ⟨0⟩ | ||
|
|
||
| -- @[simp] lemma to_fun_eq_coe : fᵥ.to_fun = ⇑fᵥ := rfl | ||
|
|
||
| -- #check ∀ v : g.V, fᵥ v | ||
|
|
||
| -- /- | ||
| -- Symmetrised product of two vectors must be a scalar | ||
| -- -/ | ||
| -- lemma vec_symm_prod_is_scalar: | ||
| -- ∀ (u v : V), ∃ k : R, (fᵥ u) * (fᵥ u) = fᵣ k := | ||
|
|
||
| end geometric_algebra | ||
|
|
||
| #lint |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
What if I have a
pointXYstructure, and I want to apply the theorems aboutPointto it?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.
This paragraph discusses how to do abstract reasoning without ever coming back to the concrete world. There was supposed to be a paragraph about what if we need to link back to the concrete world then that's where type classes come in. And I should also discuss using class v.s. structure (1:1 v.s. 1:n) as pointed out by Kevin Buzzard.