Skip to content

feat(Geometry): add Gauss-Bonnet - #517

Open
ocfnash wants to merge 4 commits into
leanprover:mainfrom
ocfnash:ocfnash/gauss_bonnet
Open

feat(Geometry): add Gauss-Bonnet#517
ocfnash wants to merge 4 commits into
leanprover:mainfrom
ocfnash:ocfnash/gauss_bonnet

Conversation

@ocfnash

@ocfnash ocfnash commented Aug 7, 2026

Copy link
Copy Markdown

No description provided.

@ocfnash
ocfnash force-pushed the ocfnash/gauss_bonnet branch from 6250fe7 to 75d2ac3 Compare August 7, 2026 17:18
@ocfnash
ocfnash force-pushed the ocfnash/gauss_bonnet branch from 75d2ac3 to 889167a Compare August 7, 2026 17:21
I am grateful to Adam Topaz for pointing out this error.

Before this change, although the _goal_ correctly accounted for the unnormalied
scaling of the Hausdorff measure, the formula `hK` did not. Since `hK` tells us
that to order `r ^ 2`, the area of a ball is `πr ^ 2`, the statement contained
a contradiction since with the unnormalied Hausdorff scaling this should be
`4r ^ 2`.

I could have fixed this bug by scaling the expression `Q` appearing in `hK`
by a factor of `4 / π` but instead decided to introduce a new measure `μ`
together with a requirement that it has the conventional scaling. This has the
advantage that both the formula for `hK` and the goal contain conventional,
familiar constants.
@kim-em

kim-em commented Aug 9, 2026

Copy link
Copy Markdown
Collaborator

🤖 Claude says:

The docstring and the hypothesis disagree on the normalisation, and it is the docstring that is wrong.

says μ = (NNReal.pi / 4) • μH[2], while the docstring says μ is "4 / π times the Hausdorff area measure". π/4 is the correct factor: Mathlib's μH is unnormalised, so on a Euclidean 2-space μH[2] = (4/π) • area, hence area = (π/4) • μH[2]. The prose has it inverted.

Worth fixing deliberately rather than as a typo, because the constant is load-bearing. If μ were c • area for any c ≠ 1, then μ (ball x r) = c(π r² - (π/12) K r⁴ + o(r⁴)), so the numerator of Q retains a (1 - c) π r² term, Q r → ∞ as r → 0⁺, and hK becomes unsatisfiable: the theorem would be vacuously true. The statement is right as it stands, but anyone "fixing" it to match the comment would silently trivialise the problem.

Since this is the declaration docstring rather than the module docstring, it also ships to solvers in the generated Challenge.lean.

@kim-em kim-em added the awaiting-author Waiting on changes from the PR author label Aug 9, 2026
Comment thread LeanEval/Geometry/GaussBonnet.lean Outdated
@ocfnash

ocfnash commented Aug 9, 2026

Copy link
Copy Markdown
Author

-awaiting-author

The "Build Generated Workspaces" CI step complains:
    error: Submission.lean:10:19: unexpected token '²'; expected ']'
So this attempts to fix that
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

awaiting-author Waiting on changes from the PR author

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants