[Merged by Bors] - refactor(Algebra/DualNumber): generalize the universal property to non-commutative rings #7934
Conversation
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
…n-commutative rings
eric-wieser
added
awaiting-review
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
leanprover-community-mathlib4-bot
added
the
blocked-by-other-PR
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
leanprover-community-mathlib4-bot
removed
the
blocked-by-other-PR
|
This PR/issue depends on:
|
1 task
leanprover-community-mathlib4-bot
added
the
merge-conflict
leanprover-community-mathlib4-bot
removed
the
merge-conflict
jcommelin
reviewed
Nov 3, 2023
Mathlib/Algebra/DualNumber.lean
Outdated
| theorem algHom_ext {A} [CommSemiring R] [Semiring A] [Algebra R A] ⦃f g : R[ε] →ₐ[R] A⦄ | ||
| (h : f ε = g ε) : f = g := | ||
| algHom_ext' <| LinearMap.ext_ring <| h | ||
| theorem algHom_ext {A} [CommSemiring R] [Semiring A] [Semiring B] [Algebra R A] [Algebra R B] |
There was a problem hiding this comment.
I think there is value in keeping the old version of ext. It is a special case, but the side conditions are a lot simpler.
There was a problem hiding this comment.
That seems fair, I've added it back. Ideally it would follow from ext <;> simp [*], but apparently some results needed to make that work are in un-imported files.
There was a problem hiding this comment.
Ah, it now works with a similar proof!
YaelDillies
reviewed
Nov 10, 2023
YaelDillies
reviewed
Nov 16, 2023
Comment on lines
+98
to
+107
| variable {A : Type*} [CommSemiring R] [Semiring A] [Semiring B] [Algebra R A] [Algebra R B] | ||
|
|
||
| /-- For two `R`-algebra morphisms out of `A[ε]` to agree, it suffices for them to agree on the | ||
| elements of `A` and the `A`-multiples of `ε`. -/ | ||
| @[ext 1100] | ||
| nonrec theorem algHom_ext' ⦃f g : A[ε] →ₐ[R] B⦄ | ||
| (hinl : f.comp (inlAlgHom _ _ _) = g.comp (inlAlgHom _ _ _)) | ||
| (hinr : f.toLinearMap ∘ₗ (LinearMap.toSpanSingleton A A[ε] ε).restrictScalars R = | ||
| g.toLinearMap ∘ₗ (LinearMap.toSpanSingleton A A[ε] ε).restrictScalars R) : | ||
| f = g := |
There was a problem hiding this comment.
Sorry, I'm failing to understand what you generalised. What was assumed commutative before which is not anymore?
There was a problem hiding this comment.
The generalization is from R[ε] →ₐ[R] B to A[ε] →ₐ[R] B, where A is not commutative
There was a problem hiding this comment.
Added to the PR description
YaelDillies
approved these changes
Nov 16, 2023
|
maintainer merge |
|
🚀 Pull request has been placed on the maintainer queue by eric-wieser. |
leanprover-community-mathlib4-bot
added
ready-to-merge
mathlib-bors bot
pushed a commit
that referenced
this pull request
Nov 17, 2023
…n-commutative rings (#7934) The current universal properties of `TrivSqZeroExt` and `DualNumber` work only when the underlying ring is commutative. This is not the case for things like the dual quaternions. This generalizes both sets of results to the non-commutative case. Unfortunately the new `TrivSqZeroExt` version is rather involved, so this keeps the old statement as a special case. The new `DualNumber` version is less bad, so I just discarded the commutative special case. For dual numbers, the generalization is from `R[ε] →ₐ[R] B` to `A[ε] →ₐ[R] B`, where `R` is commutative but `A` may not be. Some variable names had to be shuffled to make the new statement look nice.
|
Build failed: |
|
bors merge |
mathlib-bors bot
pushed a commit
that referenced
this pull request
Nov 17, 2023
…n-commutative rings (#7934) The current universal properties of `TrivSqZeroExt` and `DualNumber` work only when the underlying ring is commutative. This is not the case for things like the dual quaternions. This generalizes both sets of results to the non-commutative case. Unfortunately the new `TrivSqZeroExt` version is rather involved, so this keeps the old statement as a special case. The new `DualNumber` version is less bad, so I just discarded the commutative special case. For dual numbers, the generalization is from `R[ε] →ₐ[R] B` to `A[ε] →ₐ[R] B`, where `R` is commutative but `A` may not be. Some variable names had to be shuffled to make the new statement look nice.
mathlib-bors bot
pushed a commit
that referenced
this pull request
Nov 17, 2023
…n-commutative rings (#7934) The current universal properties of `TrivSqZeroExt` and `DualNumber` work only when the underlying ring is commutative. This is not the case for things like the dual quaternions. This generalizes both sets of results to the non-commutative case. Unfortunately the new `TrivSqZeroExt` version is rather involved, so this keeps the old statement as a special case. The new `DualNumber` version is less bad, so I just discarded the commutative special case. For dual numbers, the generalization is from `R[ε] →ₐ[R] B` to `A[ε] →ₐ[R] B`, where `R` is commutative but `A` may not be. Some variable names had to be shuffled to make the new statement look nice.
|
Pull request successfully merged into master. Build succeeded: |
mathlib-bors
bot
changed the title
alexkeizer
pushed a commit
that referenced
this pull request
Nov 21, 2023
…n-commutative rings (#7934) The current universal properties of `TrivSqZeroExt` and `DualNumber` work only when the underlying ring is commutative. This is not the case for things like the dual quaternions. This generalizes both sets of results to the non-commutative case. Unfortunately the new `TrivSqZeroExt` version is rather involved, so this keeps the old statement as a special case. The new `DualNumber` version is less bad, so I just discarded the commutative special case. For dual numbers, the generalization is from `R[ε] →ₐ[R] B` to `A[ε] →ₐ[R] B`, where `R` is commutative but `A` may not be. Some variable names had to be shuffled to make the new statement look nice.
grunweg
pushed a commit
that referenced
this pull request
Dec 15, 2023
…n-commutative rings (#7934) The current universal properties of `TrivSqZeroExt` and `DualNumber` work only when the underlying ring is commutative. This is not the case for things like the dual quaternions. This generalizes both sets of results to the non-commutative case. Unfortunately the new `TrivSqZeroExt` version is rather involved, so this keeps the old statement as a special case. The new `DualNumber` version is less bad, so I just discarded the commutative special case. For dual numbers, the generalization is from `R[ε] →ₐ[R] B` to `A[ε] →ₐ[R] B`, where `R` is commutative but `A` may not be. Some variable names had to be shuffled to make the new statement look nice.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The current universal properties of
TrivSqZeroExtandDualNumberwork only when the underlying ring is commutative.This is not the case for things like the dual quaternions.
This generalizes both sets of results to the non-commutative case.
Unfortunately the new
TrivSqZeroExtversion is rather involved, so this keeps the old statement as a special case.The new
DualNumberversion is less bad, so I just discarded the commutative special case.For dual numbers, the generalization is from
R[ε] →ₐ[R] BtoA[ε] →ₐ[R] B, whereRis commutative butAmay not be.Some variable names had to be shuffled to make the new statement look nice.
εcommutes #7928