Skip to content

Prove the Jensen-pencil bidiagonal PF preserver backend #240

Description

@PerAlexandersson

Corrected target

Prove a sound Jensen-pencil criterion implying that bidiagonalOperator preserves PF polynomials, or correct the current jensenPencilBidiagonalPreserverStatement if its normalization is insufficient.

The proof must use the genuine affine Borcea--Branden algebraic symbol. It cannot pass through the old homogeneous FiniteSymbolPF.finiteSymbol implication: that implication has a checked d = 1 counterexample recorded in #239.

Required outline

  1. Compute or invoke the exact affine symbol via finiteAlgebraicSymbol_bidiagonalLinearMap.
  2. State the exact Jensen certificate, including binomial factors, signs, and truncation.
  3. Prove that this certificate implies stability of the genuine affine symbol, or produce a counterexample and correct the certificate.
  4. Invoke only a checked affine finite-symbol sufficiency theorem from Prove the finite-symbol and homogenization stability backends #239.
  5. Derive PF/real-rootedness preservation formally from those results.

Acceptance criteria

  • Add a checked theorem, not a def ...Statement : Prop, sorry, hidden axiom, or assumption of the desired preserver conclusion.
  • Preserve the explicit jensen_backend in tactic/OEIS entry points until all normalization and finite-symbol dependencies above are checked.
  • Remove that backend only when the proved theorem applies directly; retain an explicit experimental override only if useful.
  • If a genuinely combinatorial model interpretation is supplied as an application hypothesis, place a nearby comment explaining why it is intentionally left unformalized. The stability and real-rootedness deductions must still be formal.
  • Run focused and aggregate Lake builds and report the proof witness by name.

Depends on #239. Parent: #238.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions