Samplinglib
Lean gate not recorded for this source state main · 0e31a3cda412
Registry leaf card · analysis.strong-convexity.gradient-integral-converse

strongConvexOn_univ_of_gradient_mono_integral

compiled Samplinglib leaf Not mapped explicit smoke test

- Quantitative gradient monotonicity implies the chord inequality by the source's two affine-segment FTC identities and integration of their difference. The modulus can be signed; no Hessian or extra integrability is assumed.

Plain-English statement

- Quantitative gradient monotonicity implies the chord inequality by the source's two affine-segment FTC identities and integration of their difference. The modulus can be signed; no Hessian or extra integrability is assumed.

Scope guard. This card records a compiled local declaration. Its mathematical scope is exactly the Lean statement below; the Registry note and source correspondence may describe motivation but do not strengthen it.
Lean learning studio · mathematics → formal proof

Read the mathematics first, then descend into Lean

You do not need to know Lean before opening this panel. The page keeps the paper-level theorem, rigorous proof obligations, exact Lean declaration, and proof dependencies as separate layers so a first-time reader can move down one layer at a time.

BeginnerWhy this theorem exists → intuition → statement → one hand calculation. Hide proof-engineering detail.
RigorousExpose assumptions, hidden measure/limit/domain issues, proof route, and rigorous references.
Lean learnerOpen the exact declaration, proof tree/network, syntax glossary, and line-by-line explanation.

Proof architecture

Start with the tree when learning: prerequisites sit below the theorem and downstream results sit above it. Switch to the network when you want to understand where this declaration lives in the local formal library. Every mapped node is clickable.

Loading source-derived dependency evidence…

Graph rule: only dependencies found by the ASTIS source scan are drawn. Missing tactic indirection is treated as an under-approximation; the site never invents an edge just to make a prettier graph.

How to read the exact Lean declaration

Read a Lean theorem left-to-right exactly as you would unpack a mathematical sentence: name → ambient types → automatically inferred structures → explicit hypotheses → conclusion → proof. Then read the proof top-to-bottom as transformations of the current goal.

  1. NameWhat reusable mathematical fact is being created?
  2. ParametersWhich symbols are arbitrary, and which structures are inferred by typeclass search?
  3. PropositionAfter the colon, translate the Lean expression back into a paper statement.
  4. Proof actionsAfter by, ask what each tactic does to the mathematical goal—not only what syntax it uses.

Syntax used on this page

This glossary is filtered to syntax that actually occurs in the declaration above. Open a symbol only when you meet it, rather than memorizing Lean grammar in advance.

Source voice and ASTIS voice stay separate

When Samplinglib shows a short quotation from Chewi, it is labeled as a source excerpt and linked to the canonical book page. Intuition, expanded proof steps, hidden regularity assumptions, and Lean explanations are ASTIS-authored commentary. A quotation never substitutes for a formal proof, and an ASTIS explanation is never attributed to the textbook author.

Lean statement

theorem strongConvexOn_univ_of_gradient_mono_integral
    {f : E → ℝ} {m : ℝ} (hf : ContDiff ℝ 1 f)
    (hm : ∀ x y : E, m * ‖y - x‖ ^ 2 ≤
      inner ℝ (gradient f y - gradient f x) (y - x)) :
    StrongConvexOn (univ : Set E) m f := by
  refine ⟨convex_univ, ?_⟩
  intro x _ y _ a t ha ht hat
  have hat' : a = 1 - t := by linarith
  subst a
  have ht1 : t ≤ 1 := by linarith
  rcases eq_or_lt_of_le ht1 with ht1 | ht1
  · subst t
    simp
  let v := y - x
  let A : ℝ → ℝ := fun s => inner ℝ (gradient f (x + s • v)) v
  let B : ℝ → ℝ := fun s => inner ℝ (gradient f (x + (s * t) • v)) v
  have hA : Continuous A := by
    simpa [A, gradient, Function.comp_def] using
      ((hf.continuous_fderiv (by norm_num)).comp
        (continuous_const.add (continuous_id.smul continuous_const))).clm_apply continuous_const
  have hB : Continuous B := by
    simpa [B, gradient, Function.comp_def] using
      ((hf.continuous_fderiv (by norm_num)).comp
        (continuous_const.add ((continuous_id.mul continuous_const).smul continuous_const))).clm_apply continuous_const
  have hbound : ∫ s : ℝ in 0..1, m * s * (1 - t) * ‖v‖ ^ 2 ≤
      ∫ s : ℝ in 0..1, (A s - B s) := by
    apply intervalIntegral.integral_mono_on_of_le_Ioo (by norm_num)
      ((show Continuous (fun s : ℝ => m * s * (1 - t) * ‖v‖ ^ 2) by fun_prop).intervalIntegrable 0 1)
      ((hA.sub hB).intervalIntegrable 0 1)
    intro s hs
    have h := hm (x + (s * t) • v) (x + s • v)
    have hdis : (x + s • v) - (x + (s * t) • v) = (s * (1 - t)) • v := by module
    rw [hdis, norm_smul, Real.norm_eq_abs, mul_pow, sq_abs, inner_smul_right] at h
    have hscaled : (s * (1 - t)) * (m * s * (1 - t) * ‖v‖ ^ 2) ≤
        (s * (1 - t)) * inner ℝ
          (gradient f (x + s • v) - gradient f (x + (s * t) • v)) v := by nlinarith [h]
    have hcancel := le_of_mul_le_mul_left hscaled (mul_pos hs.1 (sub_pos.mpr ht1))
    simpa [A, B, inner_sub_left] using hcancel
  have hpoly : (∫ s : ℝ in 0..1, m * s * (1 - t) * ‖v‖ ^ 2) =
      m / 2 * (1 - t) * ‖v‖ ^ 2 := by
    rw [intervalIntegral.integral_mul_const, intervalIntegral.integral_mul_const,
      intervalIntegral.integral_const_mul, integral_id]
    norm_num only [one_pow, zero_pow, sub_zero]
    ring
  rw [hpoly, intervalIntegral.integral_sub (hA.intervalIntegrable 0 1)
    (hB.intervalIntegrable 0 1)] at hbound
  have hy := sub_eq_integral_gradient hf x v
  have hz := sub_eq_integral_gradient hf x (t • v)
  have hpoint : (1 - t) • x + t • y = x + t • v := by dsimp [v]; module
  have hys : x + v = y := by simp [v]
  rw [hys] at hy
  change f y - f x = ∫ s : ℝ in 0..1, A s at hy
  simp only [smul_smul, inner_smul_right, intervalIntegral.integral_const_mul] at hz
  change f (x + t • v) - f x = t * ∫ s : ℝ in 0..1, B s at hz
  change f ((1 - t) • x + t • y) ≤ (1 - t) * f x + t * f y -
    (1 - t) * t * (m / 2 * ‖x - y‖ ^ 2)
  rw [hpoint, norm_sub_rev]
  change f (x + t • v) ≤ (1 - t) * f x + t * f y -
    (1 - t) * t * (m / 2 * ‖v‖ ^ 2)
  nlinarith [mul_le_mul_of_nonneg_left hbound ht]

/-- Proposition 1.6, part 1: on all of Euclidean space, the C¹ chord,
quadratic lower-model and gradient-monotonicity conditions are equivalent.
The nonnegative modulus is retained exactly as in the source. -/

Proof architecture

Actual parent of the exact C1 equivalence adapter; signed quadratic normalization tested

Lean proof walkthrough

  • Read the quantified variables and typeclass brackets as part of the mathematical statement; inferred arguments are not missing assumptions.
  • `intro` introduces quantified hypotheses into the local proof context.
  • `have` creates a named intermediate mathematical fact.
  • `rw` rewrites by an established identity.
  • `simp` normalizes through registered definitional and theorem rewrites.
  • `apply` reduces the goal to the hypotheses of a reusable theorem.
  • `refine` instantiates a reusable theorem while leaving explicit subgoals.
  • `simpa` closes the goal after a controlled simplification of a typed result.

Why the statement has this shape

The declaration is kept at the reusable level recorded by its Registry tags and direct consumers. Explicit measures, spaces, wrappers, and regularity hypotheses expose interfaces that paper notation often infers. A theorem card explains those interfaces but never widens the compiled statement.

Hidden assumptions and non-claims

  • Integrability is an input or proved output; a displayed integral alone does not supply it.
  • Totalized `fderiv` values must not be read as a differentiability theorem.
Common pitfall. A wrapper or display identity is not a new analytic theorem merely because it has its own Lean name. Check the statement, hypotheses, and downstream consumers before interpreting its mathematical contribution.