[Merged by Bors] - chore: fix implicit-reducible diamond in uniform convergence#38481
Closed
sgouezel wants to merge 1 commit intoleanprover-community:masterfrom
Closed
[Merged by Bors] - chore: fix implicit-reducible diamond in uniform convergence#38481sgouezel wants to merge 1 commit intoleanprover-community:masterfrom
sgouezel wants to merge 1 commit intoleanprover-community:masterfrom
Conversation
3 tasks
PR summary def28638efImport changes for modified filesNo significant changes to the import graph Import changes for all files
Declarations diff
You can run this locally as follows## summary with just the declaration names:
./scripts/pr_summary/declarations_diff.sh <optional_commit>
## more verbose report:
./scripts/pr_summary/declarations_diff.sh long <optional_commit>The doc-module for No changes to technical debt.This script lives in the
|
Contributor
|
bors merge |
mathlib-bors Bot
pushed a commit
that referenced
this pull request
Apr 30, 2026
This one is fixing a diamond which can not be encountered on master, but shows up after the fixes in #38451 (and fixing this diamond is necessary for #38451 to go through). The diamond is the following. If a space E is a C-module, then it is automatically an R-module (Module.complexToReal). Define now a type synonym E' to E, and declare that, if k acts on E, then it also acts on E', through `inferInstanceAs`. Then E' is a C-module (instance applied to k=C), and therefore an R-module by Module.complexToReal. But, as E is an R-module (by Module.complexToReal), then E' is also an R-module (by the instance applied to k=R). The two R-module structures are not the same implicit-reducibly, as the latter is hidden behind an opaque function crafted by `inferInstanceAs`. To avoid this, we define the `smul` field by hand instead of hiding it behind an opaque function. This should probably be done throughout Mathlib whenever a type synonym can be endowed with real and complex module structures. I'm just fixing one example here, because it's the one that breaks in #38451. Co-authored-by: sgouezel <sebastien.gouezel@univ-rennes1.fr>
Contributor
|
Pull request successfully merged into master. Build succeeded: |
This file contains hidden or 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
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.
This one is fixing a diamond which can not be encountered on master, but shows up after the fixes in #38451 (and fixing this diamond is necessary for #38451 to go through).
The diamond is the following. If a space E is a C-module, then it is automatically an R-module (Module.complexToReal). Define now a type synonym E' to E, and declare that, if k acts on E, then it also acts on E', through
inferInstanceAs. Then E' is a C-module (instance applied to k=C), and therefore an R-module by Module.complexToReal. But, as E is an R-module (by Module.complexToReal), then E' is also an R-module (by the instance applied to k=R). The two R-module structures are not the same implicit-reducibly, as the latter is hidden behind an opaque function crafted byinferInstanceAs.To avoid this, we define the
smulfield by hand instead of hiding it behind an opaque function. This should probably be done throughout Mathlib whenever a type synonym can be endowed with real and complex module structures. I'm just fixing one example here, because it's the one that breaks in #38451.