Skip to content

[Merged by Bors] - fix: remove defeq abuse in the Hahn-Banach theorem#34530

Closed
j-loreaux wants to merge 1 commit intoleanprover-community:masterfrom
j-loreaux:remove-extendToK-defeq-abuse
Closed

[Merged by Bors] - fix: remove defeq abuse in the Hahn-Banach theorem#34530
j-loreaux wants to merge 1 commit intoleanprover-community:masterfrom
j-loreaux:remove-extendToK-defeq-abuse

Conversation

@j-loreaux
Copy link
Copy Markdown
Contributor

This removes some erws in the proof of the Hahn-Banach theorem by using ContinuousLinearMap.extendTo𝕜' instead of the unprimed version.

While the diff adds a type ascription to the hextends argument in an obtain, so that it elaborates as ∀ x : p, g ↑x = fr x instead of ∀ x : p.restrictScalars ℝ, g ↑x = fr x, this is in fact helping to avoid defeq abuse (since the domain of fr is ↥p not ↥(p.restrictScalars ℝ)).


Open in Gitpod

@github-actions github-actions bot added the t-analysis Analysis (normed *, calculus) label Jan 28, 2026
@github-actions
Copy link
Copy Markdown

PR summary 1ad113ee44

Import changes for modified files

No significant changes to the import graph

Import changes for all files
Files Import difference

Declarations diff

No declarations were harmed in the making of this PR! 🐙

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.


Decrease in tech debt: (relative, absolute) = (3.00, 0.00)
Current number Change Type
631 -3 erw

Current commit 1796b8fc3a
Reference commit 1ad113ee44

You can run this locally as

./scripts/technical-debt-metrics.sh pr_summary
  • The relative value is the weighted sum of the differences with weight given by the inverse of the current value of the statistic.
  • The absolute value is the relative value divided by the total sum of the inverses of the current values (i.e. the weighted average of the differences).

@j-loreaux j-loreaux added the tech debt Tracking cross-cutting technical debt, see e.g. the "Technical debt counters" stream on zulip label Jan 28, 2026
Copy link
Copy Markdown
Contributor

@Ruben-VandeVelde Ruben-VandeVelde left a comment

Choose a reason for hiding this comment

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

maintainer merge

@github-actions
Copy link
Copy Markdown

🚀 Pull request has been placed on the maintainer queue by Ruben-VandeVelde.

@ghost ghost added the maintainer-merge A reviewer has approved the changed; awaiting maintainer approval. label Jan 28, 2026
Copy link
Copy Markdown
Member

@jcommelin jcommelin left a comment

Choose a reason for hiding this comment

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

Thanks 🎉

bors merge

@ghost ghost added ready-to-merge This PR has been sent to bors. and removed maintainer-merge A reviewer has approved the changed; awaiting maintainer approval. labels Jan 29, 2026
mathlib-bors bot pushed a commit that referenced this pull request Jan 29, 2026
This removes some `erw`s in the proof of the Hahn-Banach theorem by using `ContinuousLinearMap.extendTo𝕜'` instead of the unprimed version.

While the diff adds a type ascription to the `hextends` argument in an `obtain`, so that it elaborates as `∀ x : p, g ↑x = fr x` instead of `∀ x : p.restrictScalars ℝ, g ↑x = fr x`, this is in fact helping to *avoid* defeq abuse (since the domain of `fr` is `↥p` not `↥(p.restrictScalars ℝ)`).
@mathlib-bors
Copy link
Copy Markdown
Contributor

mathlib-bors bot commented Jan 29, 2026

Pull request successfully merged into master.

Build succeeded:

@mathlib-bors mathlib-bors bot changed the title fix: remove defeq abuse in the Hahn-Banach theorem [Merged by Bors] - fix: remove defeq abuse in the Hahn-Banach theorem Jan 29, 2026
@mathlib-bors mathlib-bors bot closed this Jan 29, 2026
YellPika pushed a commit to YellPika/mathlib4 that referenced this pull request Feb 3, 2026
…ity#34530)

This removes some `erw`s in the proof of the Hahn-Banach theorem by using `ContinuousLinearMap.extendTo𝕜'` instead of the unprimed version.

While the diff adds a type ascription to the `hextends` argument in an `obtain`, so that it elaborates as `∀ x : p, g ↑x = fr x` instead of `∀ x : p.restrictScalars ℝ, g ↑x = fr x`, this is in fact helping to *avoid* defeq abuse (since the domain of `fr` is `↥p` not `↥(p.restrictScalars ℝ)`).
mathlib-bors bot pushed a commit that referenced this pull request Feb 25, 2026
)

This PR concerns the extension of `ℝ`-linear (continuous or not) functionals to `𝕜`-linear functionals. This does several things, but I felt it was better to do it all at once, rather than having repeated churn in the same files because the current setup is a mess for numerous reasons. Unfortunately, that means the diff is a bit of a mess; I think the easiest way to review this PR is read the following discussion and then only look at the *new* code (and check that the deprecations exist).

I will begin by highlighting the current problems:

1. Naming: the primary declarations `LinearMap.extendTo𝕜'` and `ContinuousLinearMap.extendTo𝕜'` are in the wrong namespaces (`Module.Dual` and `StrongDual`), and contain a variable name `𝕜`.
2. These declarations are primed, and their unprimed counterparts operate directly on `RestrictScalars`. This is nominally (according to the module documentation) for convenience, but it leads to defeq abuse (see #34530) and so should be avoided anyway. That PR removes the only occurrence of the use of the unprimed declarations in Mathlib.
3. The declaration `ContinuousLinearMap.extendTo𝕜'` has type class assumptions (normed ones) that are too strong, thereby making it unusable for non-normed spaces (e.g., when one wants to consider continuous linear functionals on the weak dual of a Banach space).
4. Point (3) led to the creation of `RCLike.extendTo𝕜'ₗ` which is just `ContinuousLinearMap.extendTo𝕜'` except reproven with weaker type class assumptions and bundled into a linear map.
5. There are missing `simp` lemmas, namely, ones concerning the imaginary part of the extension applied to a vector.
6. We're missing appropriately bundled versions, with `RCLike.extendTo𝕜'ₗ` being the only bundling currently.

In this PR: we fix the above by doing the following:

1. Renaming `LinearMap.extendTo𝕜'` → `Module.Dual.extendRCLike` and `ContinuousLinearMap.extendTo𝕜'` → `StrongDual.extendRCLike`.
2. Removing the unprimed counterparts that operate on `RestrictScalars`
3. Weakening the type class assumptions on the newly renamed `StrongDual.extendRCLike`
4. Move `RCLike.extendTo𝕜'ₗ` out of its current location (`Analysis/LocallyConvex/Separation`) and next to `StrongDual.extendRCLike`; use the newly generalized `StrongDual.extendRCLike` to define it; rename it to `StrongDual.extendRCLikeₗ`; upgrade it from a linear map to a linear equivalence.
5. Add the missing simp lemmas for imaginary parts.
6. Add other appropriate bundlings, namely `Module.Dual.extendRCLikeₗ : Dual E ℝ ≃ₗ[ℝ] Dual E 𝕜`, and, in the context of normed spaces `StrongDual.extendRCLikeₗᵢ : StrongDual E ℝ ≃ₗᵢ[ℝ] StrongDual E 𝕜`.
Maldooor pushed a commit to Maldooor/mathlib4 that referenced this pull request Feb 25, 2026
…ity#34530)

This removes some `erw`s in the proof of the Hahn-Banach theorem by using `ContinuousLinearMap.extendTo𝕜'` instead of the unprimed version.

While the diff adds a type ascription to the `hextends` argument in an `obtain`, so that it elaborates as `∀ x : p, g ↑x = fr x` instead of `∀ x : p.restrictScalars ℝ, g ↑x = fr x`, this is in fact helping to *avoid* defeq abuse (since the domain of `fr` is `↥p` not `↥(p.restrictScalars ℝ)`).
pfaffelh pushed a commit to pfaffelh/mathlib4 that referenced this pull request Mar 2, 2026
…nprover-community#34543)

This PR concerns the extension of `ℝ`-linear (continuous or not) functionals to `𝕜`-linear functionals. This does several things, but I felt it was better to do it all at once, rather than having repeated churn in the same files because the current setup is a mess for numerous reasons. Unfortunately, that means the diff is a bit of a mess; I think the easiest way to review this PR is read the following discussion and then only look at the *new* code (and check that the deprecations exist).

I will begin by highlighting the current problems:

1. Naming: the primary declarations `LinearMap.extendTo𝕜'` and `ContinuousLinearMap.extendTo𝕜'` are in the wrong namespaces (`Module.Dual` and `StrongDual`), and contain a variable name `𝕜`.
2. These declarations are primed, and their unprimed counterparts operate directly on `RestrictScalars`. This is nominally (according to the module documentation) for convenience, but it leads to defeq abuse (see leanprover-community#34530) and so should be avoided anyway. That PR removes the only occurrence of the use of the unprimed declarations in Mathlib.
3. The declaration `ContinuousLinearMap.extendTo𝕜'` has type class assumptions (normed ones) that are too strong, thereby making it unusable for non-normed spaces (e.g., when one wants to consider continuous linear functionals on the weak dual of a Banach space).
4. Point (3) led to the creation of `RCLike.extendTo𝕜'ₗ` which is just `ContinuousLinearMap.extendTo𝕜'` except reproven with weaker type class assumptions and bundled into a linear map.
5. There are missing `simp` lemmas, namely, ones concerning the imaginary part of the extension applied to a vector.
6. We're missing appropriately bundled versions, with `RCLike.extendTo𝕜'ₗ` being the only bundling currently.

In this PR: we fix the above by doing the following:

1. Renaming `LinearMap.extendTo𝕜'` → `Module.Dual.extendRCLike` and `ContinuousLinearMap.extendTo𝕜'` → `StrongDual.extendRCLike`.
2. Removing the unprimed counterparts that operate on `RestrictScalars`
3. Weakening the type class assumptions on the newly renamed `StrongDual.extendRCLike`
4. Move `RCLike.extendTo𝕜'ₗ` out of its current location (`Analysis/LocallyConvex/Separation`) and next to `StrongDual.extendRCLike`; use the newly generalized `StrongDual.extendRCLike` to define it; rename it to `StrongDual.extendRCLikeₗ`; upgrade it from a linear map to a linear equivalence.
5. Add the missing simp lemmas for imaginary parts.
6. Add other appropriate bundlings, namely `Module.Dual.extendRCLikeₗ : Dual E ℝ ≃ₗ[ℝ] Dual E 𝕜`, and, in the context of normed spaces `StrongDual.extendRCLikeₗᵢ : StrongDual E ℝ ≃ₗᵢ[ℝ] StrongDual E 𝕜`.
pevogam pushed a commit to pevogam/mathlib4 that referenced this pull request Mar 19, 2026
…nprover-community#34543)

This PR concerns the extension of `ℝ`-linear (continuous or not) functionals to `𝕜`-linear functionals. This does several things, but I felt it was better to do it all at once, rather than having repeated churn in the same files because the current setup is a mess for numerous reasons. Unfortunately, that means the diff is a bit of a mess; I think the easiest way to review this PR is read the following discussion and then only look at the *new* code (and check that the deprecations exist).

I will begin by highlighting the current problems:

1. Naming: the primary declarations `LinearMap.extendTo𝕜'` and `ContinuousLinearMap.extendTo𝕜'` are in the wrong namespaces (`Module.Dual` and `StrongDual`), and contain a variable name `𝕜`.
2. These declarations are primed, and their unprimed counterparts operate directly on `RestrictScalars`. This is nominally (according to the module documentation) for convenience, but it leads to defeq abuse (see leanprover-community#34530) and so should be avoided anyway. That PR removes the only occurrence of the use of the unprimed declarations in Mathlib.
3. The declaration `ContinuousLinearMap.extendTo𝕜'` has type class assumptions (normed ones) that are too strong, thereby making it unusable for non-normed spaces (e.g., when one wants to consider continuous linear functionals on the weak dual of a Banach space).
4. Point (3) led to the creation of `RCLike.extendTo𝕜'ₗ` which is just `ContinuousLinearMap.extendTo𝕜'` except reproven with weaker type class assumptions and bundled into a linear map.
5. There are missing `simp` lemmas, namely, ones concerning the imaginary part of the extension applied to a vector.
6. We're missing appropriately bundled versions, with `RCLike.extendTo𝕜'ₗ` being the only bundling currently.

In this PR: we fix the above by doing the following:

1. Renaming `LinearMap.extendTo𝕜'` → `Module.Dual.extendRCLike` and `ContinuousLinearMap.extendTo𝕜'` → `StrongDual.extendRCLike`.
2. Removing the unprimed counterparts that operate on `RestrictScalars`
3. Weakening the type class assumptions on the newly renamed `StrongDual.extendRCLike`
4. Move `RCLike.extendTo𝕜'ₗ` out of its current location (`Analysis/LocallyConvex/Separation`) and next to `StrongDual.extendRCLike`; use the newly generalized `StrongDual.extendRCLike` to define it; rename it to `StrongDual.extendRCLikeₗ`; upgrade it from a linear map to a linear equivalence.
5. Add the missing simp lemmas for imaginary parts.
6. Add other appropriate bundlings, namely `Module.Dual.extendRCLikeₗ : Dual E ℝ ≃ₗ[ℝ] Dual E 𝕜`, and, in the context of normed spaces `StrongDual.extendRCLikeₗᵢ : StrongDual E ℝ ≃ₗᵢ[ℝ] StrongDual E 𝕜`.
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-analysis Analysis (normed *, calculus) tech debt Tracking cross-cutting technical debt, see e.g. the "Technical debt counters" stream on zulip

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants