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

[Merged by Bors] - refactor(AlgebraicGeometry/EllipticCurve/*): refactor base change for ring homomorphisms #9596

Closed
wants to merge 1 commit into from

Conversation

Multramate
Copy link
Collaborator

Refactor Weierstrass curves and nonsingular rational points to allow for base changes over an arbitrary ring homomorphism φ : K →+* L. This generalises the natural map algebraMap K L and removes the necessity for Algebra K L, but also gives an easy way to define DistribMulAction for the action of L ≃ₐ[K] L on the nonsingular rational points over L, since L ≃ₐ[K] L restricts to L →ₐ[K] L that restricts to L →+* L. The old notation W⟮L⟯ is preserved for base change over algebraMap K L.

Also remove some unnecessary coercions in the Weierstrass file.


Open in Gitpod

@Multramate Multramate added awaiting-review The author would like community review of the PR awaiting-CI t-number-theory Number theory (also use t-algebra or t-analysis to specialize) t-algebraic-geometry Algebraic geometry labels Jan 9, 2024
@riccardobrasca riccardobrasca self-assigned this Jan 10, 2024
Copy link
Member

@riccardobrasca riccardobrasca left a comment

Choose a reason for hiding this comment

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

Are you sure this modification is worth? In practice people will base change from R to an R-algebra A 95% of the times, and they will have to write algebraMap R A everywhere...

@@ -138,7 +138,7 @@ lemma YClass_ne_zero [Nontrivial R] (y : R[X]) : YClass W y ≠ 0 :=
set_option linter.uppercaseLean3 false in
#align weierstrass_curve.coordinate_ring.Y_class_ne_zero WeierstrassCurve.Affine.CoordinateRing.YClass_ne_zero

lemma C_addPolynomial (x y L : R) : mk W (C (W.addPolynomial x y L)) =
lemma C_addPolynomial (x y L : R) : mk W (C <| W.addPolynomial x y L) =
Copy link
Member

Choose a reason for hiding this comment

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

Personally I prefer the previous spelling with the parenthesis, here I think it helps readability, but as you prefer.

@Multramate
Copy link
Collaborator Author

They should not need to write algebraMap R A in most cases, as the notation W⟮A⟯ still exists for a Weierstrass curve W over R and an algebra A over R. I think it is worth it, as in the following use case:

variable {R : Type} [CommRing R] (W : Affine R) {A : Type} [Field A] [Algebra R A]

instance : DistribMulAction (A ≃ₐ[R] A) (W⟮A⟯) where
  smul := fun σ => Point.ofBaseChange W σ.toAlgHom
  one_smul := fun P => by cases P <;> rfl
  mul_smul := fun _ _ P => by cases P <;> rfl
  smul_add := fun _ => map_add _
  smul_zero := fun _ => rfl

Here, the proof for smul_add follows trivially from map_add' in ofBaseChange. In the old definition, I can't consider an arbitrary automorphism of A that fixes R since there is only algebraMap R A, and would have to rewrite the same proof.

@riccardobrasca
Copy link
Member

If there is no need to write algebraMap I am happy with the modifications, thanks!

bors d+

@mathlib-bors
Copy link
Contributor

mathlib-bors bot commented Jan 10, 2024

✌️ Multramate can now approve this pull request. To approve and merge a pull request, simply reply with bors r+. More detailed instructions are available here.

@github-actions github-actions bot added delegated and removed awaiting-review The author would like community review of the PR labels Jan 10, 2024
@Multramate
Copy link
Collaborator Author

bors r+

mathlib-bors bot pushed a commit that referenced this pull request Jan 10, 2024
… ring homomorphisms (#9596)

Refactor Weierstrass curves and nonsingular rational points to allow for base changes over an arbitrary ring homomorphism `φ : K →+* L`. This generalises the natural map `algebraMap K L` and removes the necessity for `Algebra K L`, but also gives an easy way to define `DistribMulAction` for the action of `L ≃ₐ[K] L` on the nonsingular rational points over `L`, since `L ≃ₐ[K] L` restricts to `L →ₐ[K] L` that restricts to `L →+* L`. The old notation `W⟮L⟯` is preserved for base change over `algebraMap K L`.

Also remove some unnecessary coercions in the Weierstrass file.
@mathlib-bors
Copy link
Contributor

mathlib-bors bot commented Jan 10, 2024

Pull request successfully merged into master.

Build succeeded:

@mathlib-bors mathlib-bors bot changed the title refactor(AlgebraicGeometry/EllipticCurve/*): refactor base change for ring homomorphisms [Merged by Bors] - refactor(AlgebraicGeometry/EllipticCurve/*): refactor base change for ring homomorphisms Jan 10, 2024
@mathlib-bors mathlib-bors bot closed this Jan 10, 2024
@mathlib-bors mathlib-bors bot deleted the EllipticCurve.BaseChange branch January 10, 2024 17:15
mathlib-bors bot pushed a commit that referenced this pull request Feb 19, 2024
…#9744)

This is in accordance with other similar definitions e.g. `Polynomial.map`. It turns out that rewrite lemmas of the form `(W.map (φ.comp ψ)).negY/addX/addY = ψ ((W.map φ).negY/addX/addY)` are rather annoying to use, so they are replaced with the original `baseChange` functionality that says `(W.baseChange B).negY/addX/addY = ψ ((W.baseChange A).negY/addX/addY)`. This addresses the issue in #9596 pointed out by @riccardobrasca, but for the Weierstrass curve `W` rather than its points.
mathlib-bors bot pushed a commit that referenced this pull request Feb 19, 2024
…#9744)

This is in accordance with other similar definitions e.g. `Polynomial.map`. It turns out that rewrite lemmas of the form `(W.map (φ.comp ψ)).negY/addX/addY = ψ ((W.map φ).negY/addX/addY)` are rather annoying to use, so they are replaced with the original `baseChange` functionality that says `(W.baseChange B).negY/addX/addY = ψ ((W.baseChange A).negY/addX/addY)`. This addresses the issue in #9596 pointed out by @riccardobrasca, but for the Weierstrass curve `W` rather than its points.
thorimur pushed a commit that referenced this pull request Feb 24, 2024
…#9744)

This is in accordance with other similar definitions e.g. `Polynomial.map`. It turns out that rewrite lemmas of the form `(W.map (φ.comp ψ)).negY/addX/addY = ψ ((W.map φ).negY/addX/addY)` are rather annoying to use, so they are replaced with the original `baseChange` functionality that says `(W.baseChange B).negY/addX/addY = ψ ((W.baseChange A).negY/addX/addY)`. This addresses the issue in #9596 pointed out by @riccardobrasca, but for the Weierstrass curve `W` rather than its points.
thorimur pushed a commit that referenced this pull request Feb 26, 2024
…#9744)

This is in accordance with other similar definitions e.g. `Polynomial.map`. It turns out that rewrite lemmas of the form `(W.map (φ.comp ψ)).negY/addX/addY = ψ ((W.map φ).negY/addX/addY)` are rather annoying to use, so they are replaced with the original `baseChange` functionality that says `(W.baseChange B).negY/addX/addY = ψ ((W.baseChange A).negY/addX/addY)`. This addresses the issue in #9596 pointed out by @riccardobrasca, but for the Weierstrass curve `W` rather than its points.
riccardobrasca pushed a commit that referenced this pull request Mar 1, 2024
…#9744)

This is in accordance with other similar definitions e.g. `Polynomial.map`. It turns out that rewrite lemmas of the form `(W.map (φ.comp ψ)).negY/addX/addY = ψ ((W.map φ).negY/addX/addY)` are rather annoying to use, so they are replaced with the original `baseChange` functionality that says `(W.baseChange B).negY/addX/addY = ψ ((W.baseChange A).negY/addX/addY)`. This addresses the issue in #9596 pointed out by @riccardobrasca, but for the Weierstrass curve `W` rather than its points.
dagurtomas pushed a commit that referenced this pull request Mar 22, 2024
…#9744)

This is in accordance with other similar definitions e.g. `Polynomial.map`. It turns out that rewrite lemmas of the form `(W.map (φ.comp ψ)).negY/addX/addY = ψ ((W.map φ).negY/addX/addY)` are rather annoying to use, so they are replaced with the original `baseChange` functionality that says `(W.baseChange B).negY/addX/addY = ψ ((W.baseChange A).negY/addX/addY)`. This addresses the issue in #9596 pointed out by @riccardobrasca, but for the Weierstrass curve `W` rather than its points.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
delegated t-algebraic-geometry Algebraic geometry t-number-theory Number theory (also use t-algebra or t-analysis to specialize)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants