You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Replace the [hm : HasMetric I M] typeclass auto-resolution + _g-style notation dispatch with explicit-g, method-call style throughout the Riemannian stack. The Riemannian metric g becomes a first-class Lean term in every signature; _g notations (which are currently just string suffixes hiding HasMetric.metric) are deleted in favour of g.metricInner, g.ricciTensor, etc.
End-state target (BG illustration):
theorembishopGromov_volume_comparison
(g : RiemannianMetric I M)
(hRic : ∀ x v, ((n_M : ℝ) - 1) * K * g.metricInner x v v ≤ g.ricciTensor x v v)
(p : M) ... :
dV_g[g].real B(p, R) / V_K^n_M(R) ≤ dV_g[g].real B(p, r) / V_K^n_M(r)
Throughout 9a–9e, the `_g`-style scoped notations are kept temporarily as a backward-compat layer that auto-fills `HasMetric.metric`. This lets each sub-issue's commit produce a green build with no API-surface break to downstream that hasn't migrated yet. 9f deletes the notation layer in one final atomic commit, completing the Mathlib-idiom transition.
Total scope
~1150 LOC across 17 files. Sequenced as 6 sub-PRs over multiple sessions, each one passing CI cleanly.
g.metricInner, g.metricNormSq, g.metricInnerSection, g.metricNormSqSection, g.metricRiesz all live as method-call APIs on g : RiemannianMetric I M.
Why it matters
The current _g suffix is misleading — it suggests g is a parameter, but g is hidden behind typeclass HasMetric.metric. Multiple metrics on the same manifold cannot coexist in a signature. BG's signature was forced into dV_g[(HasMetric.metric : RiemannianMetric I M)] workaround. The refactor removes this ambiguity at the foundation.
Goal
Replace the
[hm : HasMetric I M]typeclass auto-resolution +_g-style notation dispatch with explicit-g, method-call style throughout the Riemannian stack. The Riemannian metricgbecomes a first-class Lean term in every signature;_gnotations (which are currently just string suffixes hidingHasMetric.metric) are deleted in favour ofg.metricInner,g.ricciTensor, etc.End-state target (BG illustration):
Sub-issues (sequential, each session-sized)
Curvature/RicciTensorBundle.lean,RiemannCurvature.lean)Connection/LeviCivita.lean)Operators/{Gradient, Laplacian, Hessian, SecondFundamentalForm, ConnectionLaplacian})Operators/Bochner.lean+ 3 sub-files)Comparison/BG,Volume/VolumeForm,GMT/SecondVariation)_gnotations entirely, full method-call cascadePhased invariant
Throughout 9a–9e, the `_g`-style scoped notations are kept temporarily as a backward-compat layer that auto-fills `HasMetric.metric`. This lets each sub-issue's commit produce a green build with no API-surface break to downstream that hasn't migrated yet. 9f deletes the notation layer in one final atomic commit, completing the Mathlib-idiom transition.
Total scope
~1150 LOC across 17 files. Sequenced as 6 sub-PRs over multiple sessions, each one passing CI cleanly.
Foundation already in place
Metric/RiemannianMetric.leanalready explicit-g (commit6312583).g.metricInner,g.metricNormSq,g.metricInnerSection,g.metricNormSqSection,g.metricRieszall live as method-call APIs ong : RiemannianMetric I M.Why it matters
The current
_gsuffix is misleading — it suggestsgis a parameter, butgis hidden behind typeclassHasMetric.metric. Multiple metrics on the same manifold cannot coexist in a signature. BG's signature was forced intodV_g[(HasMetric.metric : RiemannianMetric I M)]workaround. The refactor removes this ambiguity at the foundation.