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: change the definition of 1 : Submodule R A to the range of (· • 1) #18092

Closed
wants to merge 4 commits into from

Conversation

alreadydone
Copy link
Contributor

@alreadydone alreadydone commented Oct 22, 2024

Previously, it's defined to be the range of algebraMap R A. In the noncommutative setting, we want to write 1 : Ideal R where Ideal R := Submodule R R, but R isn't an R-algebra if R is not commutative. If we were to introduce a new typeclass by removing the commutes' field from Algebra, we could keep the current definition, but I'd argue that it's still better to use SMul to define 1 : Submodule R A, because Submodule only depends on the Module/SMul, not on the algebraMap/RingHom.

Requires fixes in 11 other files.


Open in Gitpod

@alreadydone alreadydone added the t-algebra Algebra (groups, rings, fields, etc) label Oct 22, 2024
Copy link

github-actions bot commented Oct 22, 2024

PR summary 550d222677

Import changes for modified files

No significant changes to the import graph

Import changes for all files
Files Import difference

Declarations diff

+ toSpanSingleton_eq_algebra_linearMap

You can run this locally as follows
## summary with just the declaration names:
./scripts/declarations_diff.sh <optional_commit>

## more verbose report:
./scripts/declarations_diff.sh long <optional_commit>

The doc-module for script/declarations_diff.sh contains some details about this script.

@alreadydone alreadydone changed the title refactor: change the definition of 1 : Submodule R A to the image of (· • 1) refactor: change the definition of 1 : Submodule R A to the range of (· • 1) Oct 22, 2024
@eric-wieser
Copy link
Member

eric-wieser commented Oct 23, 2024

but I'd argue that it's still better to use SMul to define 1 : Submodule R A, because Submodule only depends on the Module/SMul, not on the algebraMap/RingHom.

I don't think I agree with this outlook idealistically; the basic premise is that the "inclusion map" has the best defeq / is most simp-normal, so if it exists it's best to use it.

However, I do agree that removing the commutes' field from Algebra is a fair bit of work.
@Vierkantor tried to do things in this direction before, and so did I. My motivation was to try and merge algebraMap wth Matrix.scalar, but it would also give us the canonical map between the groups of units in a tower of algebras etc.

It's perhaps too much work to allow it to hold up this PR, but I do think we should do it eventually.

@alreadydone
Copy link
Contributor Author

alreadydone commented Oct 23, 2024

I don't think I agree with this outlook idealistically; the basic premise is that the "inclusion map" has the best defeq / is most simp-normal, so if it exists it's best to use it.

I think r • 1 isn't much complex than algebraMap R A 1 and they are easily connected by Algebra.algebraMap_eq_smul_one (which isn't a simp lemma).

@Vierkantor tried to do things in this direction before, and so did I. My motivation was to try and merge algebraMap wth Matrix.scalar, but it would also give us the canonical map between the groups of units in a tower of algebras etc.

Yeah probably we should do it eventually. @mariainesdff is visiting and when we talked she expressed the desire to have such a class in her work. I told her the ringHomEquivModuleIsScalarTower trick but I'm not sure how useful it is.

I think there will be declarations that only require the SMul, which should only assume Module+IsScalarTower (like here), and declarations that only require the RingHom which should just use the RingHom (not a typeclass). For example, in Module.Finite.trans we wouldn't like to switch back to Algebra, even though the assumptions imply that fun r : R ↦ r • (1 : A) is a RingHom. So even when we do introduce Algebra without commutes', I don't think we should revert this PR.

@Vierkantor
Copy link
Contributor

I agree with Eric that this solution is definitely not ideal and we should be using a class with a usefully-defined inclusion map instead, even if perhaps it is just for the reason that this is morally supposed to be the "same", i.e. image, of R. And getting that more generic inclusion to work right seems to be quite hard, so I don't think either we can try to do it in a simple way here and then fix it up later.

On the other hand, I want that consideration to be remembered for future refactors, if we can ever make the inclusion work well. So I think it's okay to merge the PR with the (· • 1) definition, if we leave a TODO note and an issue about changing this when we figure out how.

Copy link
Contributor

@Vierkantor Vierkantor left a comment

Choose a reason for hiding this comment

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

LGTM, thanks!

@eric-wieser, could you do the final review please?

@jcommelin
Copy link
Member

Thanks 🎉

bors merge

@github-actions github-actions bot added the ready-to-merge This PR has been sent to bors. label Oct 26, 2024
mathlib-bors bot pushed a commit that referenced this pull request Oct 26, 2024
…f `(· • 1)` (#18092)

Previously, it's defined to be the range of `algebraMap R A`. In the noncommutative setting, we want to write `1 : Ideal R` where `Ideal R := Submodule R R`, but `R` isn't an `R`-algebra if `R` is not commutative. If we were to introduce a new typeclass by removing the `commutes'` field from `Algebra`, we could keep the current definition, but I'd argue that it's still better to use SMul to define `1 : Submodule R A`, because `Submodule` only depends on the Module/SMul, not on the algebraMap/RingHom.

Requires fixes in 11 other files.
@mathlib-bors
Copy link
Contributor

mathlib-bors bot commented Oct 26, 2024

Pull request successfully merged into master.

Build succeeded:

@mathlib-bors mathlib-bors bot changed the title refactor: change the definition of 1 : Submodule R A to the range of (· • 1) [Merged by Bors] - refactor: change the definition of 1 : Submodule R A to the range of (· • 1) Oct 26, 2024
@mathlib-bors mathlib-bors bot closed this Oct 26, 2024
@mathlib-bors mathlib-bors bot deleted the Subalgebra.one branch October 26, 2024 13:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready-to-merge This PR has been sent to bors. t-algebra Algebra (groups, rings, fields, etc)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants