3. Formal Power Series: Definition and Basic Properties
Fix a commutative ring K. For example, K can be \mathbb{Z} or
\mathbb{Q} or \mathbb{C}.
-
AlgebraicCombinatorics.FPS.fpsEquivSeq[complete]
A formal power series, or short, FPS, in 1 indeterminate over K
means a sequence
\left(a_{0},a_{1},a_{2},\ldots\right) = \left(a_{n}\right)_{n\in\mathbb{N}} \in K^{\mathbb{N}}
of elements of K.
Lean code for Definition3.1●1 definition
Associated Lean declarations
-
AlgebraicCombinatorics.FPS.fpsEquivSeq[complete]
-
AlgebraicCombinatorics.FPS.fpsEquivSeq[complete]
-
defdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
def AlgebraicCombinatorics.FPS.fpsEquivSeq.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] : PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1≃Equiv.{u_1, u_2} (α : Sort u_1) (β : Sort u_2) : Sort (max (max 1 u_1) u_2)`α ≃ β` is the type of functions from `α → β` with a two-sided inverse.(ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.→ RType u_1)def AlgebraicCombinatorics.FPS.fpsEquivSeq.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] : PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1≃Equiv.{u_1, u_2} (α : Sort u_1) (β : Sort u_2) : Sort (max (max 1 u_1) u_2)`α ≃ β` is the type of functions from `α → β` with a two-sided inverse.(ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.→ RType u_1)**Definition def.fps.fps**: The equivalence between formal power series `R⟦X⟧` and sequences `ℕ → R`. This formalizes Definition def.fps.fps from the source: a formal power series is a sequence (a₀, a₁, a₂, ...) of elements of R. The forward direction extracts coefficients, the inverse constructs the FPS.
-
AlgebraicCombinatorics.FPS.coeff_add_fps[complete] -
AlgebraicCombinatorics.FPS.coeff_sub_fps[complete] -
AlgebraicCombinatorics.FPS.coeff_smul_fps[complete] -
AlgebraicCombinatorics.FPS.coeff_mul_fps[complete] -
AlgebraicCombinatorics.FPS.coeff_C_fps[complete]
(a) The sum of two FPSs
\mathbf{a}=\left(a_{0},a_{1},a_{2},\ldots\right) and
\mathbf{b}=\left(b_{0},b_{1},b_{2},\ldots\right) is defined to be the FPS
\left(a_{0}+b_{0},\ \ a_{1}+b_{1},\ \ a_{2}+b_{2},\ \ \ldots\right).
It is denoted by \mathbf{a}+\mathbf{b}.
(b) The difference of two FPSs
\mathbf{a}=\left(a_{0},a_{1},a_{2},\ldots\right) and
\mathbf{b}=\left(b_{0},b_{1},b_{2},\ldots\right) is defined to be the FPS
\left(a_{0}-b_{0},\ \ a_{1}-b_{1},\ \ a_{2}-b_{2},\ \ \ldots\right).
It is denoted by \mathbf{a}-\mathbf{b}.
(c) If \lambda\in K and if
\mathbf{a}=\left(a_{0},a_{1},a_{2},\ldots\right) is an FPS, then we define
an FPS
\lambda\mathbf{a}:=\left(\lambda a_{0},\lambda a_{1},\lambda a_{2},\ldots\right).
(d) The product of two FPSs
\mathbf{a}=\left(a_{0},a_{1},a_{2},\ldots\right) and
\mathbf{b}=\left(b_{0},b_{1},b_{2},\ldots\right) is defined to be the FPS
\left(c_{0},c_{1},c_{2},\ldots\right), where
c_{n} =\sum_{i=0}^{n}a_{i}b_{n-i}
=\sum_{\substack{\left(i,j\right)\in\mathbb{N}^{2};\\i+j=n}}a_{i}b_{j}
=a_{0}b_{n}+a_{1}b_{n-1}+a_{2}b_{n-2}+\cdots+a_{n}b_{0}
for each n\in\mathbb{N}.
This product is denoted by \mathbf{a}\cdot\mathbf{b} or just by
\mathbf{ab}.
(e) For each a\in K, we define \underline{a} to be the FPS
\left(a,0,0,0,\ldots\right). An FPS of the form \underline{a} for some
a\in K, that is, an FPS
\left(a_{0},a_{1},a_{2},\ldots\right) satisfying
a_{1}=a_{2}=a_{3}=\cdots=0, is said to be constant.
(f) The set of all FPSs in 1 indeterminate over K is denoted
K\left[\left[x\right]\right].
Lean code for Definition3.2●5 theorems
Associated Lean declarations
-
AlgebraicCombinatorics.FPS.coeff_add_fps[complete]
-
AlgebraicCombinatorics.FPS.coeff_sub_fps[complete]
-
AlgebraicCombinatorics.FPS.coeff_smul_fps[complete]
-
AlgebraicCombinatorics.FPS.coeff_mul_fps[complete]
-
AlgebraicCombinatorics.FPS.coeff_C_fps[complete]
-
AlgebraicCombinatorics.FPS.coeff_add_fps[complete] -
AlgebraicCombinatorics.FPS.coeff_sub_fps[complete] -
AlgebraicCombinatorics.FPS.coeff_smul_fps[complete] -
AlgebraicCombinatorics.FPS.coeff_mul_fps[complete] -
AlgebraicCombinatorics.FPS.coeff_C_fps[complete]
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.coeff_add_fps.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (nℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) (fPowerSeries RgPowerSeries R: PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) (HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.fPowerSeries R+HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.gPowerSeries R)HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.(PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) fPowerSeries R+HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.(PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) gPowerSeries Rtheorem AlgebraicCombinatorics.FPS.coeff_add_fps.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (nℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) (fPowerSeries RgPowerSeries R: PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) (HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.fPowerSeries R+HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.gPowerSeries R)HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.(PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) fPowerSeries R+HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.(PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) gPowerSeries R(a) Sum of FPS is componentwise (eq. pf.thm.fps.ring.xn(a+b)=) Label: pf.thm.fps.ring.xn(a+b)=
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.coeff_sub_fps.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (nℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) (fPowerSeries RgPowerSeries R: PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) (HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).fPowerSeries R-HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).gPowerSeries R)HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.(PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) fPowerSeries R-HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).(PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) gPowerSeries Rtheorem AlgebraicCombinatorics.FPS.coeff_sub_fps.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (nℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) (fPowerSeries RgPowerSeries R: PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) (HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).fPowerSeries R-HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).gPowerSeries R)HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.(PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) fPowerSeries R-HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).(PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) gPowerSeries R(b) Difference of FPS is componentwise (eq. pf.thm.fps.ring.xn(a-b)=) Label: pf.thm.fps.ring.xn(a-b)=
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.coeff_smul_fps.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (nℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) (cR: RType u_1) (fPowerSeries R: PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) (HSMul.hSMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSMul α β γ] : α → β → γ`a • b` computes the product of `a` and `b`. The meaning of this notation is type-dependent, but it is intended to be used for left actions. Conventions for notations in identifiers: * The recommended spelling of `•` in identifiers is `smul`.cR•HSMul.hSMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSMul α β γ] : α → β → γ`a • b` computes the product of `a` and `b`. The meaning of this notation is type-dependent, but it is intended to be used for left actions. Conventions for notations in identifiers: * The recommended spelling of `•` in identifiers is `smul`.fPowerSeries R)HSMul.hSMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSMul α β γ] : α → β → γ`a • b` computes the product of `a` and `b`. The meaning of this notation is type-dependent, but it is intended to be used for left actions. Conventions for notations in identifiers: * The recommended spelling of `•` in identifiers is `smul`.=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.cR*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.(PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) fPowerSeries Rtheorem AlgebraicCombinatorics.FPS.coeff_smul_fps.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (nℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) (cR: RType u_1) (fPowerSeries R: PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) (HSMul.hSMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSMul α β γ] : α → β → γ`a • b` computes the product of `a` and `b`. The meaning of this notation is type-dependent, but it is intended to be used for left actions. Conventions for notations in identifiers: * The recommended spelling of `•` in identifiers is `smul`.cR•HSMul.hSMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSMul α β γ] : α → β → γ`a • b` computes the product of `a` and `b`. The meaning of this notation is type-dependent, but it is intended to be used for left actions. Conventions for notations in identifiers: * The recommended spelling of `•` in identifiers is `smul`.fPowerSeries R)HSMul.hSMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSMul α β γ] : α → β → γ`a • b` computes the product of `a` and `b`. The meaning of this notation is type-dependent, but it is intended to be used for left actions. Conventions for notations in identifiers: * The recommended spelling of `•` in identifiers is `smul`.=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.cR*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.(PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) fPowerSeries R(c) Scalar multiplication (eq. pf.thm.fps.ring.xn(la)=) Label: pf.thm.fps.ring.xn(la)=
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.coeff_mul_fps.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (nℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) (fPowerSeries RgPowerSeries R: PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) (HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.fPowerSeries R*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.gPowerSeries R)HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.∑ pℕ × ℕ∈ Finset.antidiagonalFinset.HasAntidiagonal.antidiagonal.{u_1} {A : Type u_1} {inst✝ : AddMonoid A} [self : Finset.HasAntidiagonal A] : A → Finset (A × A)The antidiagonal of an element `n` is the finset of pairs `(i, j)` such that `i + j = n`.nℕ, (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.pℕ × ℕ.1) fPowerSeries R*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.(PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.pℕ × ℕ.2) gPowerSeries Rtheorem AlgebraicCombinatorics.FPS.coeff_mul_fps.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (nℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) (fPowerSeries RgPowerSeries R: PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) (HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.fPowerSeries R*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.gPowerSeries R)HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.∑ pℕ × ℕ∈ Finset.antidiagonalFinset.HasAntidiagonal.antidiagonal.{u_1} {A : Type u_1} {inst✝ : AddMonoid A} [self : Finset.HasAntidiagonal A] : A → Finset (A × A)The antidiagonal of an element `n` is the finset of pairs `(i, j)` such that `i + j = n`.nℕ, (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.pℕ × ℕ.1) fPowerSeries R*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.(PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.pℕ × ℕ.2) gPowerSeries R(d) Product of FPS uses convolution (eq. pf.thm.fps.ring.xn(ab)=2) Label: pf.thm.fps.ring.xn(ab)=2
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.coeff_C_fps.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (nℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) (aR: RType u_1) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) (PowerSeries.CPowerSeries.C.{u_1} {R : Type u_1} [Semiring R] : R →+* PowerSeries RThe constant formal power series.aR) =Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.ifite.{u} {α : Sort u} (c : Prop) [h : Decidable c] (t e : α) : α`if c then t else e` is notation for `ite c t e`, "if-then-else", which decides to return `t` or `e` depending on whether `c` is true or false. The explicit argument `c : Prop` does not have any actual computational content, but there is an additional `[Decidable c]` argument synthesized by typeclass inference which actually determines how to evaluate `c` to true or false. Write `if h : c then t else e` instead for a "dependent if-then-else" `dite`, which allows `t`/`e` to use the fact that `c` is true/false.nℕ=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.0 thenite.{u} {α : Sort u} (c : Prop) [h : Decidable c] (t e : α) : α`if c then t else e` is notation for `ite c t e`, "if-then-else", which decides to return `t` or `e` depending on whether `c` is true or false. The explicit argument `c : Prop` does not have any actual computational content, but there is an additional `[Decidable c]` argument synthesized by typeclass inference which actually determines how to evaluate `c` to true or false. Write `if h : c then t else e` instead for a "dependent if-then-else" `dite`, which allows `t`/`e` to use the fact that `c` is true/false.aRelseite.{u} {α : Sort u} (c : Prop) [h : Decidable c] (t e : α) : α`if c then t else e` is notation for `ite c t e`, "if-then-else", which decides to return `t` or `e` depending on whether `c` is true or false. The explicit argument `c : Prop` does not have any actual computational content, but there is an additional `[Decidable c]` argument synthesized by typeclass inference which actually determines how to evaluate `c` to true or false. Write `if h : c then t else e` instead for a "dependent if-then-else" `dite`, which allows `t`/`e` to use the fact that `c` is true/false.0theorem AlgebraicCombinatorics.FPS.coeff_C_fps.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (nℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) (aR: RType u_1) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) (PowerSeries.CPowerSeries.C.{u_1} {R : Type u_1} [Semiring R] : R →+* PowerSeries RThe constant formal power series.aR) =Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.ifite.{u} {α : Sort u} (c : Prop) [h : Decidable c] (t e : α) : α`if c then t else e` is notation for `ite c t e`, "if-then-else", which decides to return `t` or `e` depending on whether `c` is true or false. The explicit argument `c : Prop` does not have any actual computational content, but there is an additional `[Decidable c]` argument synthesized by typeclass inference which actually determines how to evaluate `c` to true or false. Write `if h : c then t else e` instead for a "dependent if-then-else" `dite`, which allows `t`/`e` to use the fact that `c` is true/false.nℕ=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.0 thenite.{u} {α : Sort u} (c : Prop) [h : Decidable c] (t e : α) : α`if c then t else e` is notation for `ite c t e`, "if-then-else", which decides to return `t` or `e` depending on whether `c` is true or false. The explicit argument `c : Prop` does not have any actual computational content, but there is an additional `[Decidable c]` argument synthesized by typeclass inference which actually determines how to evaluate `c` to true or false. Write `if h : c then t else e` instead for a "dependent if-then-else" `dite`, which allows `t`/`e` to use the fact that `c` is true/false.aRelseite.{u} {α : Sort u} (c : Prop) [h : Decidable c] (t e : α) : α`if c then t else e` is notation for `ite c t e`, "if-then-else", which decides to return `t` or `e` depending on whether `c` is true or false. The explicit argument `c : Prop` does not have any actual computational content, but there is an additional `[Decidable c]` argument synthesized by typeclass inference which actually determines how to evaluate `c` to true or false. Write `if h : c then t else e` instead for a "dependent if-then-else" `dite`, which allows `t`/`e` to use the fact that `c` is true/false.0(e) Constant FPS: C a = (a, 0, 0, ...)
-
AlgebraicCombinatorics.FPS.fps_coeff_mk[complete]
If n\in\mathbb{N}, and if
\mathbf{a}=\left(a_{0},a_{1},a_{2},\ldots\right) \in K\left[\left[x\right]\right]
is an FPS, then we define an element
\left[x^{n}\right]\mathbf{a}\in K by
\left[x^{n}\right]\mathbf{a}:=a_{n}.
This is called the coefficient of x^{n} in \mathbf{a}, or the
n-th coefficient of \mathbf{a}, or the x^{n}-coefficient of
\mathbf{a}.
Lean code for Definition3.3●1 theorem
Associated Lean declarations
-
AlgebraicCombinatorics.FPS.fps_coeff_mk[complete]
-
AlgebraicCombinatorics.FPS.fps_coeff_mk[complete]
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.fps_coeff_mk.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (aℕ → R: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.→ RType u_1) (nℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) (PowerSeries.mkPowerSeries.mk.{u_2} {R : Type u_2} (f : ℕ → R) : PowerSeries RConstructor for formal power series.aℕ → R) =Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.aℕ → Rnℕtheorem AlgebraicCombinatorics.FPS.fps_coeff_mk.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (aℕ → R: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.→ RType u_1) (nℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) (PowerSeries.mkPowerSeries.mk.{u_2} {R : Type u_2} (f : ℕ → R) : PowerSeries RConstructor for formal power series.aℕ → R) =Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.aℕ → RnℕExtracting coefficients from an FPS gives back the original sequence (Definition def.fps.fps).
-
AlgebraicCombinatorics.FPS.smul_mul_fps[complete] -
AlgebraicCombinatorics.FPS.smul_eq_C_mul_fps[complete]
(a) The set K\left[\left[x\right]\right] is a commutative ring, with its
operations +, -, and \cdot defined above. Its zero and its unity are
the FPSs
\underline{0}=\left(0,0,0,\ldots\right) and
\underline{1}=\left(1,0,0,0,\ldots\right). Concretely, this means that:
-
Commutativity of addition: We have
\mathbf{a}+\mathbf{b}=\mathbf{b}+\mathbf{a}for all\mathbf{a},\mathbf{b}\in K\left[\left[x\right]\right]. -
Associativity of addition: We have
\mathbf{a}+\left(\mathbf{b}+\mathbf{c}\right) =\left(\mathbf{a}+\mathbf{b}\right)+\mathbf{c}for all\mathbf{a},\mathbf{b},\mathbf{c}\in K\left[\left[x\right]\right]. -
Neutrality of zero: We have
\mathbf{a}+\underline{0}=\underline{0}+\mathbf{a}=\mathbf{a}for all\mathbf{a}\in K\left[\left[x\right]\right]. -
Subtraction undoes addition: Let
\mathbf{a},\mathbf{b},\mathbf{c}\in K\left[\left[x\right]\right]. We have\mathbf{a}+\mathbf{b}=\mathbf{c}if and only if\mathbf{a}=\mathbf{c}-\mathbf{b}. -
Commutativity of multiplication: We have
\mathbf{ab}=\mathbf{ba}for all\mathbf{a},\mathbf{b}\in K\left[\left[x\right]\right]. -
Associativity of multiplication: We have
\mathbf{a}\left(\mathbf{bc}\right)=\left(\mathbf{ab}\right)\mathbf{c}for all\mathbf{a},\mathbf{b},\mathbf{c}\in K\left[\left[x\right]\right]. -
Distributivity: We have
\mathbf{a}\left(\mathbf{b}+\mathbf{c}\right)=\mathbf{ab}+\mathbf{ac} \qquad \text{and} \qquad \left(\mathbf{a}+\mathbf{b}\right)\mathbf{c}=\mathbf{ac}+\mathbf{bc}for all\mathbf{a},\mathbf{b},\mathbf{c}\in K\left[\left[x\right]\right]. -
Neutrality of one: We have
\mathbf{a}\cdot\underline{1}=\underline{1}\cdot\mathbf{a}=\mathbf{a}for all\mathbf{a}\in K\left[\left[x\right]\right]. -
Annihilation: We have
\mathbf{a}\cdot\underline{0}=\underline{0}\cdot\mathbf{a}=\underline{0}for all\mathbf{a}\in K\left[\left[x\right]\right].
(b) Furthermore, K\left[\left[x\right]\right] is a K-module, with its
scaling being the map that sends each
\left(\lambda,\mathbf{a}\right) \in K\times K\left[\left[x\right]\right]
to the FPS \lambda\mathbf{a} defined above. Its zero vector is
\underline{0}. Concretely, this means that:
-
Associativity of scaling: We have
\lambda\left(\mu\mathbf{a}\right)=\left(\lambda\mu\right)\mathbf{a}for all\lambda,\mu\in Kand\mathbf{a}\in K\left[\left[x\right]\right]. -
Left distributivity: We have
\lambda\left(\mathbf{a}+\mathbf{b}\right)=\lambda\mathbf{a}+\lambda\mathbf{b}for all\lambda\in Kand\mathbf{a},\mathbf{b}\in K\left[\left[x\right]\right]. -
Right distributivity: We have
\left(\lambda+\mu\right)\mathbf{a}=\lambda\mathbf{a}+\mu\mathbf{a}for all\lambda,\mu\in Kand\mathbf{a}\in K\left[\left[x\right]\right]. -
Neutrality of one: We have
1\mathbf{a}=\mathbf{a}for all\mathbf{a}\in K\left[\left[x\right]\right]. -
Left annihilation: We have
0\mathbf{a}=\underline{0}for all\mathbf{a}\in K\left[\left[x\right]\right]. -
Right annihilation: We have
\lambda\underline{0}=\underline{0}for all\lambda\in K.
(c) We have
\lambda\left(\mathbf{a}\cdot\mathbf{b}\right)
=\left(\lambda\mathbf{a}\right)\cdot\mathbf{b}
=\mathbf{a}\cdot\left(\lambda\mathbf{b}\right) for all
\lambda\in K and
\mathbf{a},\mathbf{b}\in K\left[\left[x\right]\right].
(d) Finally, we have
\lambda\mathbf{a}=\underline{\lambda}\cdot\mathbf{a} for all
\lambda\in K and
\mathbf{a}\in K\left[\left[x\right]\right].
Lean code for Theorem3.4●2 theorems
Associated Lean declarations
-
AlgebraicCombinatorics.FPS.smul_mul_fps[complete]
-
AlgebraicCombinatorics.FPS.smul_eq_C_mul_fps[complete]
-
AlgebraicCombinatorics.FPS.smul_mul_fps[complete] -
AlgebraicCombinatorics.FPS.smul_eq_C_mul_fps[complete]
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.smul_mul_fps.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (cR: RType u_1) (fPowerSeries RgPowerSeries R: PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) : cR•HSMul.hSMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSMul α β γ] : α → β → γ`a • b` computes the product of `a` and `b`. The meaning of this notation is type-dependent, but it is intended to be used for left actions. Conventions for notations in identifiers: * The recommended spelling of `•` in identifiers is `smul`.(HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.fPowerSeries R*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.gPowerSeries R)HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.cR•HSMul.hSMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSMul α β γ] : α → β → γ`a • b` computes the product of `a` and `b`. The meaning of this notation is type-dependent, but it is intended to be used for left actions. Conventions for notations in identifiers: * The recommended spelling of `•` in identifiers is `smul`.fPowerSeries R*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.gPowerSeries Rtheorem AlgebraicCombinatorics.FPS.smul_mul_fps.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (cR: RType u_1) (fPowerSeries RgPowerSeries R: PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) : cR•HSMul.hSMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSMul α β γ] : α → β → γ`a • b` computes the product of `a` and `b`. The meaning of this notation is type-dependent, but it is intended to be used for left actions. Conventions for notations in identifiers: * The recommended spelling of `•` in identifiers is `smul`.(HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.fPowerSeries R*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.gPowerSeries R)HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.cR•HSMul.hSMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSMul α β γ] : α → β → γ`a • b` computes the product of `a` and `b`. The meaning of this notation is type-dependent, but it is intended to be used for left actions. Conventions for notations in identifiers: * The recommended spelling of `•` in identifiers is `smul`.fPowerSeries R*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.gPowerSeries R(c) Scaling commutes with multiplication (Theorem thm.fps.ring (c))
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.smul_eq_C_mul_fps.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (cR: RType u_1) (fPowerSeries R: PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) : cR•HSMul.hSMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSMul α β γ] : α → β → γ`a • b` computes the product of `a` and `b`. The meaning of this notation is type-dependent, but it is intended to be used for left actions. Conventions for notations in identifiers: * The recommended spelling of `•` in identifiers is `smul`.fPowerSeries R=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.PowerSeries.CPowerSeries.C.{u_1} {R : Type u_1} [Semiring R] : R →+* PowerSeries RThe constant formal power series.cR*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.fPowerSeries Rtheorem AlgebraicCombinatorics.FPS.smul_eq_C_mul_fps.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (cR: RType u_1) (fPowerSeries R: PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) : cR•HSMul.hSMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSMul α β γ] : α → β → γ`a • b` computes the product of `a` and `b`. The meaning of this notation is type-dependent, but it is intended to be used for left actions. Conventions for notations in identifiers: * The recommended spelling of `•` in identifiers is `smul`.fPowerSeries R=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.PowerSeries.CPowerSeries.C.{u_1} {R : Type u_1} [Semiring R] : R →+* PowerSeries RThe constant formal power series.cR*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.fPowerSeries R(d) Scaling equals multiplication by constant (Theorem thm.fps.ring (d))
Most parts of the theorem are straightforward to verify. Let us check the associativity of multiplication.
Let \mathbf{a},\mathbf{b},\mathbf{c}\in K\left[\left[x\right]\right].
We must prove that
\mathbf{a}\left(\mathbf{bc}\right) = \left(\mathbf{ab}\right)\mathbf{c}.
Let n\in\mathbb{N}. Consider the two equalities
\left[x^{n}\right]\left(\left(\mathbf{ab}\right)\mathbf{c}\right)
=\sum_{j=0}^{n}\underbrace{\left[x^{n-j}\right]\left(\mathbf{ab}\right)}_{=\sum_{i=0}^{n-j}\left[x^{i}\right]\mathbf{a}\cdot\left[x^{n-j-i}\right]\mathbf{b}}\cdot\left[x^{j}\right]\mathbf{c}
=\sum_{j=0}^{n}\ \ \sum_{i=0}^{n-j}\left[x^{i}\right]\mathbf{a}\cdot\left[x^{n-j-i}\right]\mathbf{b}\cdot\left[x^{j}\right]\mathbf{c}
and
\left[x^{n}\right]\left(\mathbf{a}\left(\mathbf{bc}\right)\right)
=\sum_{i=0}^{n}\left[x^{i}\right]\mathbf{a}\cdot\underbrace{\left[x^{n-i}\right]\left(\mathbf{bc}\right)}_{=\sum_{j=0}^{n-i}\left[x^{n-i-j}\right]\mathbf{b}\cdot\left[x^{j}\right]\mathbf{c}}
=\sum_{i=0}^{n}\ \ \sum_{j=0}^{n-i}\left[x^{i}\right]\mathbf{a}\cdot\left[x^{n-i-j}\right]\mathbf{b}\cdot\left[x^{j}\right]\mathbf{c}.
The right hand sides are equal since
\sum_{j=0}^{n}\ \ \sum_{i=0}^{n-j}
=\sum_{\substack{\left(i,j\right)\in\mathbb{N}^{2};\\i+j\leq n}}
=\sum_{i=0}^{n}\ \ \sum_{j=0}^{n-i}
and n-j-i=n-i-j.
Thus
\left[x^{n}\right]\left(\left(\mathbf{ab}\right)\mathbf{c}\right)
=\left[x^{n}\right]\left(\mathbf{a}\left(\mathbf{bc}\right)\right) for each
n\in\mathbb{N}, which entails
\left(\mathbf{ab}\right)\mathbf{c}=\mathbf{a}\left(\mathbf{bc}\right).
The remaining claims of the theorem follow by similar, and easier, coefficient-wise verifications. In the Lean formalization, the commutative ring and module structures are provided by Mathlib's existing instances on power series.
The product formula can be written as a sum over a range:
\left[x^{n}\right]\left(\mathbf{ab}\right)
= \sum_{i=0}^{n}\left[x^{i}\right]\mathbf{a}\cdot\left[x^{n-i}\right]\mathbf{b}.
Lean code for Lemma3.5●1 theorem
Associated Lean declarations
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.coeff_mul_fps'.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (nℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) (fPowerSeries RgPowerSeries R: PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) (HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.fPowerSeries R*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.gPowerSeries R)HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.∑ iℕ∈ Finset.rangeFinset.range (n : ℕ) : Finset ℕ`range n` is the set of natural numbers less than `n`.(HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.nℕ+HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.1)HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`., (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.iℕ) fPowerSeries R*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.(PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.(HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).nℕ-HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).iℕ)HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).) gPowerSeries Rtheorem AlgebraicCombinatorics.FPS.coeff_mul_fps'.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (nℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) (fPowerSeries RgPowerSeries R: PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) (HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.fPowerSeries R*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.gPowerSeries R)HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.∑ iℕ∈ Finset.rangeFinset.range (n : ℕ) : Finset ℕ`range n` is the set of natural numbers less than `n`.(HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.nℕ+HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.1)HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`., (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.iℕ) fPowerSeries R*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.(PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.(HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).nℕ-HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).iℕ)HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).) gPowerSeries RAlternative form of product formula (eq. pf.thm.fps.ring.xn(ab)=3) Label: pf.thm.fps.ring.xn(ab)=3
This rewrites the antidiagonal sum from the product definition as a range sum
using the bijection (i, n-i) \leftrightarrow i \in \{0, \ldots, n\}.
(a) A family \left(a_{i}\right)_{i\in I}\in K^{I} of elements of
K is said to be essentially finite if all but finitely many
i\in I satisfy a_{i}=0, in other words, if the set
\left\{i\in I\mid a_{i}\neq0\right\} is finite.
(b) Let \left(a_{i}\right)_{i\in I}\in K^{I} be an essentially finite
family of elements of K. Then the infinite sum \sum_{i\in I}a_{i} is
defined to equal the finite sum
\sum_{\substack{i\in I;\\a_{i}\neq0}}a_{i}. Such an infinite sum is said
to be essentially finite.
Lean code for Definition3.6●1 definition
Associated Lean declarations
-
abbrevdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
abbrev AlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} (fι → R: ιType u_2→ RType u_1) : PropThe universe of propositions. `Prop ≡ Sort 0`. Every proposition is propositionally equal to either `True` or `False`.abbrev AlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} (fι → R: ιType u_2→ RType u_1) : PropThe universe of propositions. `Prop ≡ Sort 0`. Every proposition is propositionally equal to either `True` or `False`.A family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.
-
AlgebraicCombinatorics.FPS.SummableFPS[complete] -
AlgebraicCombinatorics.FPS.summableFPSSum[complete]
A possibly infinite family \left(\mathbf{a}_{i}\right)_{i\in I} of FPSs is
said to be summable, or entrywise essentially finite, if
\text{for each }n\in\mathbb{N}\text{, all but finitely many }i\in I\text{ satisfy }\left[x^{n}\right]\mathbf{a}_{i}=0.
In this case, the sum \sum_{i\in I}\mathbf{a}_{i} is defined to be the FPS
with
\left[x^{n}\right]\left(\sum_{i\in I}\mathbf{a}_{i}\right)
=\underbrace{\sum_{i\in I}\left[x^{n}\right]\mathbf{a}_{i}}_{\substack{\text{an essentially}\\\text{finite sum}}}
\qquad \text{for all }n\in\mathbb{N}.
Lean code for Definition3.7●2 definitions
Associated Lean declarations
-
AlgebraicCombinatorics.FPS.SummableFPS[complete]
-
AlgebraicCombinatorics.FPS.summableFPSSum[complete]
-
AlgebraicCombinatorics.FPS.SummableFPS[complete] -
AlgebraicCombinatorics.FPS.summableFPSSum[complete]
-
defdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
def AlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} (fι → PowerSeries R: ιType u_2→ PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) : PropThe universe of propositions. `Prop ≡ Sort 0`. Every proposition is propositionally equal to either `True` or `False`.def AlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} (fι → PowerSeries R: ιType u_2→ PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) : PropThe universe of propositions. `Prop ≡ Sort 0`. Every proposition is propositionally equal to either `True` or `False`.A family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)
-
defdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
def AlgebraicCombinatorics.FPS.summableFPSSum.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} (fι → PowerSeries R: ιType u_2→ PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) (_hfFPS.SummableFPS f: FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fι → PowerSeries R) : PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1def AlgebraicCombinatorics.FPS.summableFPSSum.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} (fι → PowerSeries R: ιType u_2→ PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) (_hfFPS.SummableFPS f: FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fι → PowerSeries R) : PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1The sum of a summable family of FPS. (Definition def.fps.summable, eq. eq.def.fps.summable.sum) For a summable family (fᵢ)_{i ∈ I}, the sum ∑_{i ∈ I} fᵢ is the FPS whose n-th coefficient is ∑_{i ∈ I} [x^n] fᵢ (an essentially finite sum).
Let \left(\mathbf{a}_{i}\right)_{i\in I} be a summable family of FPSs.
Then any subfamily of \left(\mathbf{a}_{i}\right)_{i\in I} is summable as
well.
Lean code for Theorem3.8●1 theorem
Associated Lean declarations
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.summableFPS_subfamily.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} {fι → PowerSeries R: ιType u_2→ PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1} (JSet ι: SetSet.{u} (α : Type u) : Type uA set is a collection of elements of some type `α`. Although `Set` is defined as `α → Prop`, this is an implementation detail which should not be relied on. Instead, `setOf` and membership of a set (`∈`) should be used to convert between sets and predicates.ιType u_2) (hfFPS.SummableFPS f: FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fι → PowerSeries R) : FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fun i↑J↦ fι → PowerSeries R↑i↑Jtheorem AlgebraicCombinatorics.FPS.summableFPS_subfamily.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} {fι → PowerSeries R: ιType u_2→ PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1} (JSet ι: SetSet.{u} (α : Type u) : Type uA set is a collection of elements of some type `α`. Although `Set` is defined as `α → Prop`, this is an implementation detail which should not be relied on. Instead, `setOf` and membership of a set (`∈`) should be used to convert between sets and predicates.ιType u_2) (hfFPS.SummableFPS f: FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fι → PowerSeries R) : FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fun i↑J↦ fι → PowerSeries R↑i↑JAny subfamily of a summable family of FPS is summable. (Proposition prop.fps.summable.sub)
Let J be a subset of I. We must prove that the subfamily
\left(\mathbf{a}_{i}\right)_{i\in J} is summable.
Let n\in\mathbb{N}. Then all but finitely many i\in I satisfy
\left[x^{n}\right]\mathbf{a}_{i}=0, since
\left(\mathbf{a}_{i}\right)_{i\in I} is summable. Hence all but finitely
many i\in J satisfy \left[x^{n}\right]\mathbf{a}_{i}=0, since J is a
subset of I. Since we have proved this for each n\in\mathbb{N}, we
conclude that the family \left(\mathbf{a}_{i}\right)_{i\in J} is summable.
Sums of summable families of FPSs satisfy the usual rules for sums, such as
the breaking-apart rule
\sum_{i\in S}a_{s}=\sum_{i\in X}a_{s}+\sum_{i\in Y}a_{s} when a set
S is the union of two disjoint sets X and Y.
Again, the only caveat is about interchange of summation signs: the equality
\sum_{i\in I}\ \ \sum_{j\in J}\mathbf{a}_{i,j}
=\sum_{j\in J}\ \ \sum_{i\in I}\mathbf{a}_{i,j}
holds when the family
\left(\mathbf{a}_{i,j}\right)_{\left(i,j\right)\in I\times J} is summable,
that is, when for each n\in\mathbb{N}, all but finitely many pairs
\left(i,j\right)\in I\times J satisfy
\left[x^{n}\right]\mathbf{a}_{i,j}=0; it does not generally hold if we
merely assume that the sums
\sum_{i\in I}\ \ \sum_{j\in J}\mathbf{a}_{i,j} and
\sum_{j\in J}\ \ \sum_{i\in I}\mathbf{a}_{i,j} are summable.
Lean code for Theorem3.9●1 theorem
Associated Lean declarations
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.summableFPS_fubini.{u_1, u_2, u_3} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} {κType u_3: Type u_3A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} {fι × κ → PowerSeries R: ιType u_2×Prod.{u, v} (α : Type u) (β : Type v) : Type (max u v)The product type, usually written `α × β`. Product types are also called pair or tuple types. Elements of this type are pairs in which the first element is an `α` and the second element is a `β`. Products nest to the right, so `(x, y, z) : α × β × γ` is equivalent to `(x, (y, z)) : α × (β × γ)`. Conventions for notations in identifiers: * The recommended spelling of `×` in identifiers is `Prod`.κType u_3→ PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1} (hfFPS.SummableFPS f: FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fι × κ → PowerSeries R) : (∀ (iι: ιType u_2), FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fun jκ↦ fι × κ → PowerSeries R(Prod.mk.{u, v} {α : Type u} {β : Type v} (fst : α) (snd : β) : α × βConstructs a pair. This is usually written `(x, y)` instead of `Prod.mk x y`. Conventions for notations in identifiers: * The recommended spelling of `(a, b)` in identifiers is `mk`.iι,Prod.mk.{u, v} {α : Type u} {β : Type v} (fst : α) (snd : β) : α × βConstructs a pair. This is usually written `(x, y)` instead of `Prod.mk x y`. Conventions for notations in identifiers: * The recommended spelling of `(a, b)` in identifiers is `mk`.jκ)Prod.mk.{u, v} {α : Type u} {β : Type v} (fst : α) (snd : β) : α × βConstructs a pair. This is usually written `(x, y)` instead of `Prod.mk x y`. Conventions for notations in identifiers: * The recommended spelling of `(a, b)` in identifiers is `mk`.) ∧And (a b : Prop) : Prop`And a b`, or `a ∧ b`, is the conjunction of propositions. It can be constructed and destructed like a pair: if `ha : a` and `hb : b` then `⟨ha, hb⟩ : a ∧ b`, and if `h : a ∧ b` then `h.left : a` and `h.right : b`. Conventions for notations in identifiers: * The recommended spelling of `∧` in identifiers is `and`. * The recommended spelling of `/\` in identifiers is `and` (prefer `∧` over `/\`).∀ (jκ: κType u_3), FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fun iι↦ fι × κ → PowerSeries R(Prod.mk.{u, v} {α : Type u} {β : Type v} (fst : α) (snd : β) : α × βConstructs a pair. This is usually written `(x, y)` instead of `Prod.mk x y`. Conventions for notations in identifiers: * The recommended spelling of `(a, b)` in identifiers is `mk`.iι,Prod.mk.{u, v} {α : Type u} {β : Type v} (fst : α) (snd : β) : α × βConstructs a pair. This is usually written `(x, y)` instead of `Prod.mk x y`. Conventions for notations in identifiers: * The recommended spelling of `(a, b)` in identifiers is `mk`.jκ)Prod.mk.{u, v} {α : Type u} {β : Type v} (fst : α) (snd : β) : α × βConstructs a pair. This is usually written `(x, y)` instead of `Prod.mk x y`. Conventions for notations in identifiers: * The recommended spelling of `(a, b)` in identifiers is `mk`.theorem AlgebraicCombinatorics.FPS.summableFPS_fubini.{u_1, u_2, u_3} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} {κType u_3: Type u_3A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} {fι × κ → PowerSeries R: ιType u_2×Prod.{u, v} (α : Type u) (β : Type v) : Type (max u v)The product type, usually written `α × β`. Product types are also called pair or tuple types. Elements of this type are pairs in which the first element is an `α` and the second element is a `β`. Products nest to the right, so `(x, y, z) : α × β × γ` is equivalent to `(x, (y, z)) : α × (β × γ)`. Conventions for notations in identifiers: * The recommended spelling of `×` in identifiers is `Prod`.κType u_3→ PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1} (hfFPS.SummableFPS f: FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fι × κ → PowerSeries R) : (∀ (iι: ιType u_2), FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fun jκ↦ fι × κ → PowerSeries R(Prod.mk.{u, v} {α : Type u} {β : Type v} (fst : α) (snd : β) : α × βConstructs a pair. This is usually written `(x, y)` instead of `Prod.mk x y`. Conventions for notations in identifiers: * The recommended spelling of `(a, b)` in identifiers is `mk`.iι,Prod.mk.{u, v} {α : Type u} {β : Type v} (fst : α) (snd : β) : α × βConstructs a pair. This is usually written `(x, y)` instead of `Prod.mk x y`. Conventions for notations in identifiers: * The recommended spelling of `(a, b)` in identifiers is `mk`.jκ)Prod.mk.{u, v} {α : Type u} {β : Type v} (fst : α) (snd : β) : α × βConstructs a pair. This is usually written `(x, y)` instead of `Prod.mk x y`. Conventions for notations in identifiers: * The recommended spelling of `(a, b)` in identifiers is `mk`.) ∧And (a b : Prop) : Prop`And a b`, or `a ∧ b`, is the conjunction of propositions. It can be constructed and destructed like a pair: if `ha : a` and `hb : b` then `⟨ha, hb⟩ : a ∧ b`, and if `h : a ∧ b` then `h.left : a` and `h.right : b`. Conventions for notations in identifiers: * The recommended spelling of `∧` in identifiers is `and`. * The recommended spelling of `/\` in identifiers is `and` (prefer `∧` over `/\`).∀ (jκ: κType u_3), FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fun iι↦ fι × κ → PowerSeries R(Prod.mk.{u, v} {α : Type u} {β : Type v} (fst : α) (snd : β) : α × βConstructs a pair. This is usually written `(x, y)` instead of `Prod.mk x y`. Conventions for notations in identifiers: * The recommended spelling of `(a, b)` in identifiers is `mk`.iι,Prod.mk.{u, v} {α : Type u} {β : Type v} (fst : α) (snd : β) : α × βConstructs a pair. This is usually written `(x, y)` instead of `Prod.mk x y`. Conventions for notations in identifiers: * The recommended spelling of `(a, b)` in identifiers is `mk`.jκ)Prod.mk.{u, v} {α : Type u} {β : Type v} (fst : α) (snd : β) : α × βConstructs a pair. This is usually written `(x, y)` instead of `Prod.mk x y`. Conventions for notations in identifiers: * The recommended spelling of `(a, b)` in identifiers is `mk`.The Fubini rule for summable FPS families: interchange of summation is valid when the family indexed by the product is summable. (Proposition prop.fps.summable-sums-rule, discrete Fubini rule) Note: The actual sum computation requires Mathlib's topological sum machinery. This theorem states that the summability condition on the product implies summability of the iterated sums.
The proof is tedious, because there are many rules to check, but fairly
straightforward: always focus on a single coefficient, and then reduce the
infinite sums to finite sums. For example, consider the discrete Fubini rule,
which says that
\sum_{i\in I}\ \ \sum_{j\in J}\mathbf{a}_{i,j}
=\sum_{\left(i,j\right)\in I\times J}\mathbf{a}_{i,j}
=\sum_{j\in J}\ \ \sum_{i\in I}\mathbf{a}_{i,j}
whenever \left(\mathbf{a}_{i,j}\right)_{\left(i,j\right)\in I\times J} is
a summable family of FPSs.
To prove this rule, fix such a summable family. It is easy to see that the
families \left(\mathbf{a}_{i,j}\right)_{j\in J} for all i\in I are
summable as well, as are the families
\left(\mathbf{a}_{i,j}\right)_{i\in I} for all j\in J, and the families
\left(\sum_{j\in J}\mathbf{a}_{i,j}\right)_{i\in I} and
\left(\sum_{i\in I}\mathbf{a}_{i,j}\right)_{j\in J}.
To verify the Fubini identity, it suffices to check that
\left[x^{n}\right]\left(\sum_{i\in I}\ \ \sum_{j\in J}\mathbf{a}_{i,j}\right)
=\left[x^{n}\right]\left(\sum_{\left(i,j\right)\in I\times J}\mathbf{a}_{i,j}\right)
=\left[x^{n}\right]\left(\sum_{j\in J}\ \ \sum_{i\in I}\mathbf{a}_{i,j}\right)
for each n\in\mathbb{N}.
Fix n\in\mathbb{N}. Then
\left[x^{n}\right]\left(\mathbf{a}_{i,j}\right)=0 for all but finitely many
\left(i,j\right)\in I\times J, since the family is summable. Thus the set
of all pairs \left(i,j\right)\in I\times J satisfying
\left[x^{n}\right]\left(\mathbf{a}_{i,j}\right)\neq0 is finite. Hence the
set I^{\prime} of first entries and the set J^{\prime} of second entries
of all these pairs are also finite. The three sums reduce to finite sums over
I^{\prime}\times J^{\prime}, which are equal by the usual Fubini rule for
finite sums.
-
AlgebraicCombinatorics.FPS.X_coeff_one[complete] -
AlgebraicCombinatorics.FPS.X_coeff_ne_one[complete]
Let x denote the FPS \left(0,1,0,0,0,\ldots\right).
In other words, let x denote the FPS with
\left[x^{1}\right]x=1 and \left[x^{i}\right]x=0 for all i\neq1.
Lean code for Definition3.10●2 theorems
Associated Lean declarations
-
AlgebraicCombinatorics.FPS.X_coeff_one[complete]
-
AlgebraicCombinatorics.FPS.X_coeff_ne_one[complete]
-
AlgebraicCombinatorics.FPS.X_coeff_one[complete] -
AlgebraicCombinatorics.FPS.X_coeff_ne_one[complete]
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.X_coeff_one.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.1) PowerSeries.XPowerSeries.X.{u_1} {R : Type u_1} [Semiring R] : PowerSeries RThe variable of the formal power series ring.=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.1theorem AlgebraicCombinatorics.FPS.X_coeff_one.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.1) PowerSeries.XPowerSeries.X.{u_1} {R : Type u_1} [Semiring R] : PowerSeries RThe variable of the formal power series ring.=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.1x = (0, 1, 0, 0, ...) (Definition def.fps.x)
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.X_coeff_ne_one.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (iℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) (hii ≠ 1: iℕ≠Ne.{u} {α : Sort u} (a b : α) : Prop`a ≠ b`, or `Ne a b` is defined as `¬ (a = b)` or `a = b → False`, and asserts that `a` and `b` are not equal. Conventions for notations in identifiers: * The recommended spelling of `≠` in identifiers is `ne`.1) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.iℕ) PowerSeries.XPowerSeries.X.{u_1} {R : Type u_1} [Semiring R] : PowerSeries RThe variable of the formal power series ring.=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.0theorem AlgebraicCombinatorics.FPS.X_coeff_ne_one.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (iℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) (hii ≠ 1: iℕ≠Ne.{u} {α : Sort u} (a b : α) : Prop`a ≠ b`, or `Ne a b` is defined as `¬ (a = b)` or `a = b → False`, and asserts that `a` and `b` are not equal. Conventions for notations in identifiers: * The recommended spelling of `≠` in identifiers is `ne`.1) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.iℕ) PowerSeries.XPowerSeries.X.{u_1} {R : Type u_1} [Semiring R] : PowerSeries RThe variable of the formal power series ring.=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.0
-
AlgebraicCombinatorics.FPS.X_mul_shift[complete] -
AlgebraicCombinatorics.FPS.X_mul_coeff_zero[complete] -
AlgebraicCombinatorics.FPS.coeff_X_mul[complete]
Let \mathbf{a}=\left(a_{0},a_{1},a_{2},\ldots\right) be an FPS.
Then
x\cdot\mathbf{a}=\left(0,a_{0},a_{1},a_{2},\ldots\right).
Lean code for Lemma3.11●3 theorems
Associated Lean declarations
-
AlgebraicCombinatorics.FPS.X_mul_shift[complete]
-
AlgebraicCombinatorics.FPS.X_mul_coeff_zero[complete]
-
AlgebraicCombinatorics.FPS.coeff_X_mul[complete]
-
AlgebraicCombinatorics.FPS.X_mul_shift[complete] -
AlgebraicCombinatorics.FPS.X_mul_coeff_zero[complete] -
AlgebraicCombinatorics.FPS.coeff_X_mul[complete]
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.X_mul_shift.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (fPowerSeries R: PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) (nℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.(HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.nℕ+HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.1)HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.) (HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.PowerSeries.XPowerSeries.X.{u_1} {R : Type u_1} [Semiring R] : PowerSeries RThe variable of the formal power series ring.*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.fPowerSeries R)HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.(PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) fPowerSeries Rtheorem AlgebraicCombinatorics.FPS.X_mul_shift.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (fPowerSeries R: PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) (nℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.(HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.nℕ+HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.1)HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.) (HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.PowerSeries.XPowerSeries.X.{u_1} {R : Type u_1} [Semiring R] : PowerSeries RThe variable of the formal power series ring.*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.fPowerSeries R)HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.(PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) fPowerSeries RMultiplying by x shifts coefficients: [x^{n+1}](X·f) = [x^n]f (Lemma lem.fps.xa) -
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.X_mul_coeff_zero.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (fPowerSeries R: PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.0) (HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.PowerSeries.XPowerSeries.X.{u_1} {R : Type u_1} [Semiring R] : PowerSeries RThe variable of the formal power series ring.*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.fPowerSeries R)HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.0theorem AlgebraicCombinatorics.FPS.X_mul_coeff_zero.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (fPowerSeries R: PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.0) (HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.PowerSeries.XPowerSeries.X.{u_1} {R : Type u_1} [Semiring R] : PowerSeries RThe variable of the formal power series ring.*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.fPowerSeries R)HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.0The constant term of X * f is 0 (Lemma lem.fps.xa, case n = 0)
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.coeff_X_mul.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (fPowerSeries R: PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) (nℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) (HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.PowerSeries.XPowerSeries.X.{u_1} {R : Type u_1} [Semiring R] : PowerSeries RThe variable of the formal power series ring.*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.fPowerSeries R)HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.ifite.{u} {α : Sort u} (c : Prop) [h : Decidable c] (t e : α) : α`if c then t else e` is notation for `ite c t e`, "if-then-else", which decides to return `t` or `e` depending on whether `c` is true or false. The explicit argument `c : Prop` does not have any actual computational content, but there is an additional `[Decidable c]` argument synthesized by typeclass inference which actually determines how to evaluate `c` to true or false. Write `if h : c then t else e` instead for a "dependent if-then-else" `dite`, which allows `t`/`e` to use the fact that `c` is true/false.nℕ=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.0 thenite.{u} {α : Sort u} (c : Prop) [h : Decidable c] (t e : α) : α`if c then t else e` is notation for `ite c t e`, "if-then-else", which decides to return `t` or `e` depending on whether `c` is true or false. The explicit argument `c : Prop` does not have any actual computational content, but there is an additional `[Decidable c]` argument synthesized by typeclass inference which actually determines how to evaluate `c` to true or false. Write `if h : c then t else e` instead for a "dependent if-then-else" `dite`, which allows `t`/`e` to use the fact that `c` is true/false.0 elseite.{u} {α : Sort u} (c : Prop) [h : Decidable c] (t e : α) : α`if c then t else e` is notation for `ite c t e`, "if-then-else", which decides to return `t` or `e` depending on whether `c` is true or false. The explicit argument `c : Prop` does not have any actual computational content, but there is an additional `[Decidable c]` argument synthesized by typeclass inference which actually determines how to evaluate `c` to true or false. Write `if h : c then t else e` instead for a "dependent if-then-else" `dite`, which allows `t`/`e` to use the fact that `c` is true/false.(PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.(HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).nℕ-HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).1)HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).) fPowerSeries Rtheorem AlgebraicCombinatorics.FPS.coeff_X_mul.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (fPowerSeries R: PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) (nℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) (HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.PowerSeries.XPowerSeries.X.{u_1} {R : Type u_1} [Semiring R] : PowerSeries RThe variable of the formal power series ring.*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.fPowerSeries R)HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.ifite.{u} {α : Sort u} (c : Prop) [h : Decidable c] (t e : α) : α`if c then t else e` is notation for `ite c t e`, "if-then-else", which decides to return `t` or `e` depending on whether `c` is true or false. The explicit argument `c : Prop` does not have any actual computational content, but there is an additional `[Decidable c]` argument synthesized by typeclass inference which actually determines how to evaluate `c` to true or false. Write `if h : c then t else e` instead for a "dependent if-then-else" `dite`, which allows `t`/`e` to use the fact that `c` is true/false.nℕ=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.0 thenite.{u} {α : Sort u} (c : Prop) [h : Decidable c] (t e : α) : α`if c then t else e` is notation for `ite c t e`, "if-then-else", which decides to return `t` or `e` depending on whether `c` is true or false. The explicit argument `c : Prop` does not have any actual computational content, but there is an additional `[Decidable c]` argument synthesized by typeclass inference which actually determines how to evaluate `c` to true or false. Write `if h : c then t else e` instead for a "dependent if-then-else" `dite`, which allows `t`/`e` to use the fact that `c` is true/false.0 elseite.{u} {α : Sort u} (c : Prop) [h : Decidable c] (t e : α) : α`if c then t else e` is notation for `ite c t e`, "if-then-else", which decides to return `t` or `e` depending on whether `c` is true or false. The explicit argument `c : Prop` does not have any actual computational content, but there is an additional `[Decidable c]` argument synthesized by typeclass inference which actually determines how to evaluate `c` to true or false. Write `if h : c then t else e` instead for a "dependent if-then-else" `dite`, which allows `t`/`e` to use the fact that `c` is true/false.(PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.(HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).nℕ-HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).1)HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).) fPowerSeries RComplete characterization of multiplication by X (Lemma lem.fps.xa, unified form) If f = (a₀, a₁, a₂, ...), then X * f = (0, a₀, a₁, a₂, ...) This is equivalent to: [x^n](X·f) = if n = 0 then 0 else [x^{n-1}]f
If n is a positive integer, then
\left[x^{n}\right]\left(x\cdot\mathbf{a}\right)
=\sum_{i=0}^{n}\left[x^{i}\right]x\cdot a_{n-i}
=\underbrace{\left[x^{0}\right]x}_{=0}\cdot a_{n}
+\underbrace{\left[x^{1}\right]x}_{=1}\cdot a_{n-1}
+\sum_{i=2}^{n}\underbrace{\left[x^{i}\right]x}_{=0}\cdot a_{n-i}
=a_{n-1}.
A similar argument for n=0 yields
\left[x^{0}\right]\left(x\cdot\mathbf{a}\right)=0.
Thus, for each n\in\mathbb{N},
\left[x^{n}\right]\left(x\cdot\mathbf{a}\right)=
\begin{cases}
a_{n-1}, & \text{if }n>0;\\
0, & \text{if }n=0.
\end{cases}
In other words,
x\cdot\mathbf{a}=\left(0,a_{0},a_{1},a_{2},\ldots\right).
-
AlgebraicCombinatorics.FPS.X_pow_coeff[complete]
We have
x^{k}=\left(\underbrace{0,0,\ldots,0}_{k\text{ times}},1,0,0,0,\ldots\right)
\qquad\text{for each }k\in\mathbb{N}.
Lean code for Theorem3.12●1 theorem
Associated Lean declarations
-
AlgebraicCombinatorics.FPS.X_pow_coeff[complete]
-
AlgebraicCombinatorics.FPS.X_pow_coeff[complete]
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.X_pow_coeff.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (kℕnℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) (HPow.hPow.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HPow α β γ] : α → β → γ`a ^ b` computes `a` to the power of `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `^` in identifiers is `pow`.PowerSeries.XPowerSeries.X.{u_1} {R : Type u_1} [Semiring R] : PowerSeries RThe variable of the formal power series ring.^HPow.hPow.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HPow α β γ] : α → β → γ`a ^ b` computes `a` to the power of `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `^` in identifiers is `pow`.kℕ)HPow.hPow.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HPow α β γ] : α → β → γ`a ^ b` computes `a` to the power of `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `^` in identifiers is `pow`.=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.ifite.{u} {α : Sort u} (c : Prop) [h : Decidable c] (t e : α) : α`if c then t else e` is notation for `ite c t e`, "if-then-else", which decides to return `t` or `e` depending on whether `c` is true or false. The explicit argument `c : Prop` does not have any actual computational content, but there is an additional `[Decidable c]` argument synthesized by typeclass inference which actually determines how to evaluate `c` to true or false. Write `if h : c then t else e` instead for a "dependent if-then-else" `dite`, which allows `t`/`e` to use the fact that `c` is true/false.nℕ=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.kℕthenite.{u} {α : Sort u} (c : Prop) [h : Decidable c] (t e : α) : α`if c then t else e` is notation for `ite c t e`, "if-then-else", which decides to return `t` or `e` depending on whether `c` is true or false. The explicit argument `c : Prop` does not have any actual computational content, but there is an additional `[Decidable c]` argument synthesized by typeclass inference which actually determines how to evaluate `c` to true or false. Write `if h : c then t else e` instead for a "dependent if-then-else" `dite`, which allows `t`/`e` to use the fact that `c` is true/false.1 elseite.{u} {α : Sort u} (c : Prop) [h : Decidable c] (t e : α) : α`if c then t else e` is notation for `ite c t e`, "if-then-else", which decides to return `t` or `e` depending on whether `c` is true or false. The explicit argument `c : Prop` does not have any actual computational content, but there is an additional `[Decidable c]` argument synthesized by typeclass inference which actually determines how to evaluate `c` to true or false. Write `if h : c then t else e` instead for a "dependent if-then-else" `dite`, which allows `t`/`e` to use the fact that `c` is true/false.0theorem AlgebraicCombinatorics.FPS.X_pow_coeff.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (kℕnℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) (HPow.hPow.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HPow α β γ] : α → β → γ`a ^ b` computes `a` to the power of `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `^` in identifiers is `pow`.PowerSeries.XPowerSeries.X.{u_1} {R : Type u_1} [Semiring R] : PowerSeries RThe variable of the formal power series ring.^HPow.hPow.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HPow α β γ] : α → β → γ`a ^ b` computes `a` to the power of `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `^` in identifiers is `pow`.kℕ)HPow.hPow.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HPow α β γ] : α → β → γ`a ^ b` computes `a` to the power of `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `^` in identifiers is `pow`.=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.ifite.{u} {α : Sort u} (c : Prop) [h : Decidable c] (t e : α) : α`if c then t else e` is notation for `ite c t e`, "if-then-else", which decides to return `t` or `e` depending on whether `c` is true or false. The explicit argument `c : Prop` does not have any actual computational content, but there is an additional `[Decidable c]` argument synthesized by typeclass inference which actually determines how to evaluate `c` to true or false. Write `if h : c then t else e` instead for a "dependent if-then-else" `dite`, which allows `t`/`e` to use the fact that `c` is true/false.nℕ=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.kℕthenite.{u} {α : Sort u} (c : Prop) [h : Decidable c] (t e : α) : α`if c then t else e` is notation for `ite c t e`, "if-then-else", which decides to return `t` or `e` depending on whether `c` is true or false. The explicit argument `c : Prop` does not have any actual computational content, but there is an additional `[Decidable c]` argument synthesized by typeclass inference which actually determines how to evaluate `c` to true or false. Write `if h : c then t else e` instead for a "dependent if-then-else" `dite`, which allows `t`/`e` to use the fact that `c` is true/false.1 elseite.{u} {α : Sort u} (c : Prop) [h : Decidable c] (t e : α) : α`if c then t else e` is notation for `ite c t e`, "if-then-else", which decides to return `t` or `e` depending on whether `c` is true or false. The explicit argument `c : Prop` does not have any actual computational content, but there is an additional `[Decidable c]` argument synthesized by typeclass inference which actually determines how to evaluate `c` to true or false. Write `if h : c then t else e` instead for a "dependent if-then-else" `dite`, which allows `t`/`e` to use the fact that `c` is true/false.0x^k has 1 in position k and 0 elsewhere (Proposition prop.fps.xk)
We induct on k.
Induction base: We have
x^{0}=\underline{1}=\left(1,0,0,0,0,\ldots\right)
=\left(\underbrace{0,0,\ldots,0}_{0\text{ times}},1,0,0,0,\ldots\right).
Induction step: Let m\in\mathbb{N} and assume the proposition holds for
k=m. Then
x^{m}=\left(\underbrace{0,0,\ldots,0}_{m\text{ times}},1,0,0,0,\ldots\right).
Applying the previous lemma to \mathbf{a}=x^{m} yields
x\cdot x^{m}
=\left(0,\underbrace{0,0,\ldots,0}_{m\text{ times}},1,0,0,0,\ldots\right)
=\left(\underbrace{0,0,\ldots,0}_{m+1\text{ times}},1,0,0,0,\ldots\right).
Since x\cdot x^{m}=x^{m+1}, this completes the induction step.
Any FPS
\left(a_{0},a_{1},a_{2},\ldots\right)\in K\left[\left[x\right]\right]
satisfies
\left(a_{0},a_{1},a_{2},\ldots\right)
= a_{0}+a_{1}x+a_{2}x^{2}+a_{3}x^{3}+\cdots
= \sum_{n\in\mathbb{N}}a_{n}x^{n}.
In particular, the right hand side is well-defined, that is, the family
\left(a_{n}x^{n}\right)_{n\in\mathbb{N}} is summable.
Lean code for Corollary3.13●2 theorems
Associated Lean declarations
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.fps_eq_tsum_coeff.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (fPowerSeries R: PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) : fPowerSeries R=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.PowerSeries.mkPowerSeries.mk.{u_2} {R : Type u_2} (f : ℕ → R) : PowerSeries RConstructor for formal power series.fun nℕ↦ (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) fPowerSeries Rtheorem AlgebraicCombinatorics.FPS.fps_eq_tsum_coeff.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (fPowerSeries R: PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) : fPowerSeries R=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.PowerSeries.mkPowerSeries.mk.{u_2} {R : Type u_2} (f : ℕ → R) : PowerSeries RConstructor for formal power series.fun nℕ↦ (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) fPowerSeries RThe family (aₙ x^n)_{n ∈ ℕ} represents the FPS with coefficients (aₙ). This is essentially saying PowerSeries.mk a = ∑ a n * X^n (Corollary cor.fps.sumakxk) -
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.summableFPS_monomial_family.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (aℕ → R: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.→ RType u_1) : FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fun nℕ↦ PowerSeries.CPowerSeries.C.{u_1} {R : Type u_1} [Semiring R] : R →+* PowerSeries RThe constant formal power series.(aℕ → Rnℕ) *HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.PowerSeries.XPowerSeries.X.{u_1} {R : Type u_1} [Semiring R] : PowerSeries RThe variable of the formal power series ring.^HPow.hPow.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HPow α β γ] : α → β → γ`a ^ b` computes `a` to the power of `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `^` in identifiers is `pow`.nℕtheorem AlgebraicCombinatorics.FPS.summableFPS_monomial_family.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (aℕ → R: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.→ RType u_1) : FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fun nℕ↦ PowerSeries.CPowerSeries.C.{u_1} {R : Type u_1} [Semiring R] : R →+* PowerSeries RThe constant formal power series.(aℕ → Rnℕ) *HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.PowerSeries.XPowerSeries.X.{u_1} {R : Type u_1} [Semiring R] : PowerSeries RThe variable of the formal power series ring.^HPow.hPow.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HPow α β γ] : α → β → γ`a ^ b` computes `a` to the power of `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `^` in identifiers is `pow`.nℕThe family (C(aₙ) * X^n)_{n ∈ ℕ} is summable for any sequence (aₙ). This is the canonical example showing that any FPS can be written as an infinite sum ∑_{n ∈ ℕ} aₙ x^n.
By the previous proposition, we have
a_{0}+a_{1}x+a_{2}x^{2}+a_{3}x^{3}+\cdots
= a_{0}\left(1,0,0,0,\ldots\right)
+ a_{1}\left(0,1,0,0,\ldots\right)
+ a_{2}\left(0,0,1,0,\ldots\right)
+ a_{3}\left(0,0,0,1,\ldots\right)+\cdots
and hence
= \left(a_{0},0,0,0,\ldots\right)
+ \left(0,a_{1},0,0,\ldots\right)
+ \left(0,0,a_{2},0,\ldots\right)
+ \left(0,0,0,a_{3},\ldots\right)+\cdots
=\left(a_{0},a_{1},a_{2},a_{3},\ldots\right).
- Lemma 3.15
- Lemma 3.16
- Lemma 3.17
- Lemma 3.18
- Definition 3.19
- Lemma 3.20
- Lemma 3.21
- Lemma 3.22
- Lemma 3.23
If \left(\mathbf{a}_{i}\right)_{i\in I} and
\left(\mathbf{b}_{i}\right)_{i\in I} are summable families of FPSs, then
so is \left(\mathbf{a}_{i}+\mathbf{b}_{i}\right)_{i\in I}.
Lean code for Lemma3.14●1 theorem
Associated Lean declarations
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.summableFPS_add.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} {fι → PowerSeries Rgι → PowerSeries R: ιType u_2→ PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1} (hfFPS.SummableFPS f: FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fι → PowerSeries R) (hgFPS.SummableFPS g: FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)gι → PowerSeries R) : FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fun iι↦ fι → PowerSeries Riι+HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.gι → PowerSeries Riιtheorem AlgebraicCombinatorics.FPS.summableFPS_add.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} {fι → PowerSeries Rgι → PowerSeries R: ιType u_2→ PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1} (hfFPS.SummableFPS f: FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fι → PowerSeries R) (hgFPS.SummableFPS g: FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)gι → PowerSeries R) : FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fun iι↦ fι → PowerSeries Riι+HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.gι → PowerSeries RiιSum of two summable families is summable.
For each n\in\mathbb{N},
\{i \mid \left[x^{n}\right](\mathbf{a}_{i}+\mathbf{b}_{i})\neq 0\}
\subseteq \{i \mid \left[x^{n}\right]\mathbf{a}_{i}\neq 0\} \cup
\{i \mid \left[x^{n}\right]\mathbf{b}_{i}\neq 0\}, and the union of two
finite sets is finite.
- Lemma 3.14
- Lemma 3.16
- Lemma 3.17
- Lemma 3.18
- Definition 3.19
- Lemma 3.20
- Lemma 3.21
- Lemma 3.22
- Lemma 3.23
If \left(\mathbf{a}_{i}\right)_{i\in I} is a summable family of FPSs, then
so is \left(-\mathbf{a}_{i}\right)_{i\in I}.
Lean code for Lemma3.15●1 theorem
Associated Lean declarations
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.summableFPS_neg.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} {fι → PowerSeries R: ιType u_2→ PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1} (hfFPS.SummableFPS f: FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fι → PowerSeries R) : FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fun iι↦ -Neg.neg.{u} {α : Type u} [self : Neg α] : α → α`-a` computes the negative or opposite of `a`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `neg` (when used as a unary operator).fι → PowerSeries Riιtheorem AlgebraicCombinatorics.FPS.summableFPS_neg.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} {fι → PowerSeries R: ιType u_2→ PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1} (hfFPS.SummableFPS f: FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fι → PowerSeries R) : FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fun iι↦ -Neg.neg.{u} {α : Type u} [self : Neg α] : α → α`-a` computes the negative or opposite of `a`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `neg` (when used as a unary operator).fι → PowerSeries RiιNegation of a summable family is summable.
For each n,
\left[x^{n}\right](-\mathbf{a}_{i})=-\left[x^{n}\right]\mathbf{a}_{i}, so
\{i \mid \left[x^{n}\right](-\mathbf{a}_{i})\neq 0\}
= \{i \mid \left[x^{n}\right]\mathbf{a}_{i}\neq 0\}.
- Lemma 3.14
- Lemma 3.15
- Lemma 3.17
- Lemma 3.18
- Definition 3.19
- Lemma 3.20
- Lemma 3.21
- Lemma 3.22
- Lemma 3.23
The sum of two essentially finite families is essentially finite.
Lean code for Lemma3.16●1 theorem
Associated Lean declarations
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.essentiallyFinite_add.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} {fι → Rgι → R: ιType u_2→ RType u_1} (hfFPS.EssentiallyFinite f: FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.fι → R) (hgFPS.EssentiallyFinite g: FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.gι → R) : FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.fun iι↦ fι → Riι+HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.gι → Riιtheorem AlgebraicCombinatorics.FPS.essentiallyFinite_add.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} {fι → Rgι → R: ιType u_2→ RType u_1} (hfFPS.EssentiallyFinite f: FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.fι → R) (hgFPS.EssentiallyFinite g: FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.gι → R) : FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.fun iι↦ fι → Riι+HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.gι → RiιSum of two essentially finite families is essentially finite. (Delegates to `_root_.EssentiallyFinite.add`)
\{i \mid a_{i}+b_{i}\neq 0\}\subseteq \{i \mid a_{i}\neq 0\}\cup\{i \mid b_{i}\neq 0\},
and the union of two finite sets is finite.
- Lemma 3.14
- Lemma 3.15
- Lemma 3.16
- Lemma 3.18
- Definition 3.19
- Lemma 3.20
- Lemma 3.21
- Lemma 3.22
- Lemma 3.23
The negation of an essentially finite family is essentially finite.
Lean code for Lemma3.17●1 theorem
Associated Lean declarations
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.essentiallyFinite_neg.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} {fι → R: ιType u_2→ RType u_1} (hfFPS.EssentiallyFinite f: FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.fι → R) : FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.fun iι↦ -Neg.neg.{u} {α : Type u} [self : Neg α] : α → α`-a` computes the negative or opposite of `a`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `neg` (when used as a unary operator).fι → Riιtheorem AlgebraicCombinatorics.FPS.essentiallyFinite_neg.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} {fι → R: ιType u_2→ RType u_1} (hfFPS.EssentiallyFinite f: FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.fι → R) : FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.fun iι↦ -Neg.neg.{u} {α : Type u} [self : Neg α] : α → α`-a` computes the negative or opposite of `a`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `neg` (when used as a unary operator).fι → RiιNegation of an essentially finite family is essentially finite. (Delegates to `_root_.EssentiallyFinite.neg`)
\{i \mid -a_{i}\neq 0\}=\{i \mid a_{i}\neq 0\}.
- Lemma 3.14
- Lemma 3.15
- Lemma 3.16
- Lemma 3.17
- Definition 3.19
- Lemma 3.20
- Lemma 3.21
- Lemma 3.22
- Lemma 3.23
The difference of two essentially finite families is essentially finite.
Lean code for Lemma3.18●1 theorem
Associated Lean declarations
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.essentiallyFinite_sub.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} {fι → Rgι → R: ιType u_2→ RType u_1} (hfFPS.EssentiallyFinite f: FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.fι → R) (hgFPS.EssentiallyFinite g: FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.gι → R) : FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.fun iι↦ fι → Riι-HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).gι → Riιtheorem AlgebraicCombinatorics.FPS.essentiallyFinite_sub.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} {fι → Rgι → R: ιType u_2→ RType u_1} (hfFPS.EssentiallyFinite f: FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.fι → R) (hgFPS.EssentiallyFinite g: FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.gι → R) : FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.fun iι↦ fι → Riι-HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).gι → RiιSubtraction of two essentially finite families is essentially finite. (Delegates to `_root_.EssentiallyFinite.sub`)
Write a_i - b_i = a_i + (-b_i) and apply the previous essentially finite
addition and negation lemmas.
-
AlgebraicCombinatorics.FPS.essFinSum[complete]
For an essentially finite family (a_i)_{i\in I}, the essentially finite
sum \sum_{i\in I} a_i is defined as \sum_{i\in S} a_i where
S = \{i\in I \mid a_i \neq 0\}.
Lean code for Definition3.19●1 definition
Associated Lean declarations
-
AlgebraicCombinatorics.FPS.essFinSum[complete]
-
AlgebraicCombinatorics.FPS.essFinSum[complete]
-
defdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
def AlgebraicCombinatorics.FPS.essFinSum.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} (fι → R: ιType u_2→ RType u_1) (hfFPS.EssentiallyFinite f: FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.fι → R) : RType u_1def AlgebraicCombinatorics.FPS.essFinSum.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} (fι → R: ιType u_2→ RType u_1) (hfFPS.EssentiallyFinite f: FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.fι → R) : RType u_1The sum of an essentially finite family, defined as the finite sum over non-zero elements. (Definition def.infsum.essfin (b))
- Lemma 3.14
- Lemma 3.15
- Lemma 3.16
- Lemma 3.17
- Lemma 3.18
- Definition 3.19
- Lemma 3.21
- Lemma 3.22
- Lemma 3.23
-
AlgebraicCombinatorics.FPS.essFinSum_add[complete]
The essentially finite sum distributes over addition: if
(a_i)_{i\in I} and (b_i)_{i\in I} are essentially finite families, then
\sum_{i\in I}(a_i + b_i) = \sum_{i\in I} a_i + \sum_{i\in I} b_i.
Lean code for Lemma3.20●1 theorem
Associated Lean declarations
-
AlgebraicCombinatorics.FPS.essFinSum_add[complete]
-
AlgebraicCombinatorics.FPS.essFinSum_add[complete]
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.essFinSum_add.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [DecidableEqDecidableEq.{u} (α : Sort u) : Sort (max 1 u)Propositional equality is `Decidable` for all elements of a type. In other words, an instance of `DecidableEq α` is a means of deciding the proposition `a = b` is for all `a b : α`.ιType u_2] {fι → Rgι → R: ιType u_2→ RType u_1} (hfFPS.EssentiallyFinite f: FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.fι → R) (hgFPS.EssentiallyFinite g: FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.gι → R) (hfgFPS.EssentiallyFinite fun i ↦ f i + g i: FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.fun iι↦ fι → Riι+HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.gι → Riι) : FPS.essFinSumAlgebraicCombinatorics.FPS.essFinSum.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) (hf : FPS.EssentiallyFinite f) : RThe sum of an essentially finite family, defined as the finite sum over non-zero elements. (Definition def.infsum.essfin (b))(fun iι↦ fι → Riι+HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.gι → Riι) hfgFPS.EssentiallyFinite fun i ↦ f i + g i=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.FPS.essFinSumAlgebraicCombinatorics.FPS.essFinSum.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) (hf : FPS.EssentiallyFinite f) : RThe sum of an essentially finite family, defined as the finite sum over non-zero elements. (Definition def.infsum.essfin (b))fι → RhfFPS.EssentiallyFinite f+HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.FPS.essFinSumAlgebraicCombinatorics.FPS.essFinSum.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) (hf : FPS.EssentiallyFinite f) : RThe sum of an essentially finite family, defined as the finite sum over non-zero elements. (Definition def.infsum.essfin (b))gι → RhgFPS.EssentiallyFinite gtheorem AlgebraicCombinatorics.FPS.essFinSum_add.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [DecidableEqDecidableEq.{u} (α : Sort u) : Sort (max 1 u)Propositional equality is `Decidable` for all elements of a type. In other words, an instance of `DecidableEq α` is a means of deciding the proposition `a = b` is for all `a b : α`.ιType u_2] {fι → Rgι → R: ιType u_2→ RType u_1} (hfFPS.EssentiallyFinite f: FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.fι → R) (hgFPS.EssentiallyFinite g: FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.gι → R) (hfgFPS.EssentiallyFinite fun i ↦ f i + g i: FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.fun iι↦ fι → Riι+HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.gι → Riι) : FPS.essFinSumAlgebraicCombinatorics.FPS.essFinSum.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) (hf : FPS.EssentiallyFinite f) : RThe sum of an essentially finite family, defined as the finite sum over non-zero elements. (Definition def.infsum.essfin (b))(fun iι↦ fι → Riι+HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.gι → Riι) hfgFPS.EssentiallyFinite fun i ↦ f i + g i=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.FPS.essFinSumAlgebraicCombinatorics.FPS.essFinSum.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) (hf : FPS.EssentiallyFinite f) : RThe sum of an essentially finite family, defined as the finite sum over non-zero elements. (Definition def.infsum.essfin (b))fι → RhfFPS.EssentiallyFinite f+HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.FPS.essFinSumAlgebraicCombinatorics.FPS.essFinSum.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) (hf : FPS.EssentiallyFinite f) : RThe sum of an essentially finite family, defined as the finite sum over non-zero elements. (Definition def.infsum.essfin (b))gι → RhgFPS.EssentiallyFinite gAdditivity: the essentially finite sum of a sum is the sum of essentially finite sums
All three sums can be computed over the finite set
S = \{i \mid a_i\neq 0\}\cup\{i \mid b_i\neq 0\}, so this reduces to the
finite sum identity
\sum_{i\in S}(a_i+b_i)=\sum_{i\in S}a_i+\sum_{i\in S}b_i.
- Lemma 3.14
- Lemma 3.15
- Lemma 3.16
- Lemma 3.17
- Lemma 3.18
- Definition 3.19
- Lemma 3.20
- Lemma 3.22
- Lemma 3.23
For a scalar c\in K and an essentially finite family
(a_i)_{i\in I},
\sum_{i\in I} c\, a_i = c\cdot\sum_{i\in I} a_i.
Lean code for Lemma3.21●1 theorem
Associated Lean declarations
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.essFinSum_smul.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} {fι → R: ιType u_2→ RType u_1} (cR: RType u_1) (hfFPS.EssentiallyFinite f: FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.fι → R) (hcfFPS.EssentiallyFinite fun i ↦ c * f i: FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.fun iι↦ cR*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.fι → Riι) : FPS.essFinSumAlgebraicCombinatorics.FPS.essFinSum.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) (hf : FPS.EssentiallyFinite f) : RThe sum of an essentially finite family, defined as the finite sum over non-zero elements. (Definition def.infsum.essfin (b))(fun iι↦ cR*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.fι → Riι) hcfFPS.EssentiallyFinite fun i ↦ c * f i=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.cR*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.FPS.essFinSumAlgebraicCombinatorics.FPS.essFinSum.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) (hf : FPS.EssentiallyFinite f) : RThe sum of an essentially finite family, defined as the finite sum over non-zero elements. (Definition def.infsum.essfin (b))fι → RhfFPS.EssentiallyFinite ftheorem AlgebraicCombinatorics.FPS.essFinSum_smul.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} {fι → R: ιType u_2→ RType u_1} (cR: RType u_1) (hfFPS.EssentiallyFinite f: FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.fι → R) (hcfFPS.EssentiallyFinite fun i ↦ c * f i: FPS.EssentiallyFiniteAlgebraicCombinatorics.FPS.EssentiallyFinite.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) : PropA family is essentially finite if its support is finite. (Definition def.infsum.essfin (a)) **This is an alias** for the canonical `EssentiallyFinite` defined in `FPS/InfiniteProducts2.lean`. Both definitions are **definitionally equal**: `{i | f i ≠ 0}.Finite` = `(Function.support f).Finite` by definition. For the full API (including `_root_.EssentiallyFinite.add`, `_root_.EssentiallyFinite.neg`, `_root_.EssentiallyFinite.toFinsupp`, etc.), see `FPS/InfiniteProducts2.lean`.fun iι↦ cR*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.fι → Riι) : FPS.essFinSumAlgebraicCombinatorics.FPS.essFinSum.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) (hf : FPS.EssentiallyFinite f) : RThe sum of an essentially finite family, defined as the finite sum over non-zero elements. (Definition def.infsum.essfin (b))(fun iι↦ cR*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.fι → Riι) hcfFPS.EssentiallyFinite fun i ↦ c * f i=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.cR*HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.FPS.essFinSumAlgebraicCombinatorics.FPS.essFinSum.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → R) (hf : FPS.EssentiallyFinite f) : RThe sum of an essentially finite family, defined as the finite sum over non-zero elements. (Definition def.infsum.essfin (b))fι → RhfFPS.EssentiallyFinite fScalar multiplication: c * (∑ aᵢ) = ∑ (c * aᵢ)
The support of (c\,a_i) is contained in the support of (a_i), so this
reduces to the finite identity
\sum_{i\in S}c\,a_i = c\sum_{i\in S}a_i.
- Lemma 3.14
- Lemma 3.15
- Lemma 3.16
- Lemma 3.17
- Lemma 3.18
- Definition 3.19
- Lemma 3.20
- Lemma 3.21
- Lemma 3.23
If \left(\mathbf{a}_{i}\right)_{i\in I} and
\left(\mathbf{b}_{i}\right)_{i\in I} are summable families of FPSs, then so
is \left(\mathbf{a}_{i}-\mathbf{b}_{i}\right)_{i\in I}.
Lean code for Lemma3.22●1 theorem
Associated Lean declarations
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.summableFPS_sub.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} {fι → PowerSeries Rgι → PowerSeries R: ιType u_2→ PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1} (hfFPS.SummableFPS f: FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fι → PowerSeries R) (hgFPS.SummableFPS g: FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)gι → PowerSeries R) : FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fun iι↦ fι → PowerSeries Riι-HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).gι → PowerSeries Riιtheorem AlgebraicCombinatorics.FPS.summableFPS_sub.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} {fι → PowerSeries Rgι → PowerSeries R: ιType u_2→ PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1} (hfFPS.SummableFPS f: FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fι → PowerSeries R) (hgFPS.SummableFPS g: FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)gι → PowerSeries R) : FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fun iι↦ fι → PowerSeries Riι-HSub.hSub.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HSub α β γ] : α → β → γ`a - b` computes the difference of `a` and `b`. The meaning of this notation is type-dependent. * For natural numbers, this operator saturates at 0: `a - b = 0` when `a ≤ b`. Conventions for notations in identifiers: * The recommended spelling of `-` in identifiers is `sub` (when used as a binary operator).gι → PowerSeries RiιSubtraction of two summable families is summable.
Write \mathbf{a}_i - \mathbf{b}_i = \mathbf{a}_i + (-\mathbf{b}_i) and
apply the previous summable-add and summable-neg lemmas.
- Lemma 3.14
- Lemma 3.15
- Lemma 3.16
- Lemma 3.17
- Lemma 3.18
- Definition 3.19
- Lemma 3.20
- Lemma 3.21
- Lemma 3.22
If (\mathbf{a}_i)_{i\in I} is a family of FPSs such that
\{i \mid \mathbf{a}_i \neq 0\} is finite, then the family is summable.
Lean code for Lemma3.23●1 theorem
Associated Lean declarations
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.summableFPS_of_essentiallyFinite.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} (fι → PowerSeries R: ιType u_2→ PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) (hf{i | f i ≠ 0}.Finite: {setOf.{u} {α : Type u} (p : α → Prop) : Set αTurn a predicate `p : α → Prop` into a set, also written as `{x | p x}`iι|setOf.{u} {α : Type u} (p : α → Prop) : Set αTurn a predicate `p : α → Prop` into a set, also written as `{x | p x}`fι → PowerSeries Riι≠Ne.{u} {α : Sort u} (a b : α) : Prop`a ≠ b`, or `Ne a b` is defined as `¬ (a = b)` or `a = b → False`, and asserts that `a` and `b` are not equal. Conventions for notations in identifiers: * The recommended spelling of `≠` in identifiers is `ne`.0}setOf.{u} {α : Type u} (p : α → Prop) : Set αTurn a predicate `p : α → Prop` into a set, also written as `{x | p x}`.FiniteSet.Finite.{u} {α : Type u} (s : Set α) : PropA set is finite if the corresponding `Subtype` is finite, i.e., if there exists a natural `n : ℕ` and an equivalence `s ≃ Fin n`.) : FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fι → PowerSeries Rtheorem AlgebraicCombinatorics.FPS.summableFPS_of_essentiallyFinite.{u_1, u_2} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] {ιType u_2: Type u_2A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} (fι → PowerSeries R: ιType u_2→ PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1) (hf{i | f i ≠ 0}.Finite: {setOf.{u} {α : Type u} (p : α → Prop) : Set αTurn a predicate `p : α → Prop` into a set, also written as `{x | p x}`iι|setOf.{u} {α : Type u} (p : α → Prop) : Set αTurn a predicate `p : α → Prop` into a set, also written as `{x | p x}`fι → PowerSeries Riι≠Ne.{u} {α : Sort u} (a b : α) : Prop`a ≠ b`, or `Ne a b` is defined as `¬ (a = b)` or `a = b → False`, and asserts that `a` and `b` are not equal. Conventions for notations in identifiers: * The recommended spelling of `≠` in identifiers is `ne`.0}setOf.{u} {α : Type u} (p : α → Prop) : Set αTurn a predicate `p : α → Prop` into a set, also written as `{x | p x}`.FiniteSet.Finite.{u} {α : Type u} (s : Set α) : PropA set is finite if the corresponding `Subtype` is finite, i.e., if there exists a natural `n : ℕ` and an equivalence `s ≃ Fin n`.) : FPS.SummableFPSAlgebraicCombinatorics.FPS.SummableFPS.{u_1, u_2} {R : Type u_1} [CommRing R] {ι : Type u_2} (f : ι → PowerSeries R) : PropA family of FPS is summable if for each coefficient index n, all but finitely many family members have that coefficient equal to zero. (Definition def.fps.summable)fι → PowerSeries RAn essentially finite family of FPS is summable.
For each n,
\{i \mid [x^n]\mathbf{a}_i \neq 0\} \subseteq \{i \mid \mathbf{a}_i \neq 0\},
which is finite by hypothesis.
The ordinary generating function of a sequence
(a_0, a_1, a_2, \ldots) is the FPS
(a_0, a_1, a_2, \ldots) = \sum_{n\geq 0} a_n x^n.
Lean code for Definition3.24●1 definition
Associated Lean declarations
-
defdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
def AlgebraicCombinatorics.FPS.generatingFunction.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} (aℕ → R: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.→ RType u_1) : PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1def AlgebraicCombinatorics.FPS.generatingFunction.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} (aℕ → R: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.→ RType u_1) : PowerSeriesPowerSeries.{u_1} (R : Type u_1) : Type u_1Formal power series over a coefficient type `R`RType u_1The generating function of a sequence is just the FPS with those coefficients
The n-th coefficient of the generating function of a sequence
(a_n) is a_n.
Lean code for Lemma3.25●1 theorem
Associated Lean declarations
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.generatingFunction_coeff.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (aℕ → R: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.→ RType u_1) (nℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) (FPS.generatingFunctionAlgebraicCombinatorics.FPS.generatingFunction.{u_1} {R : Type u_1} (a : ℕ → R) : PowerSeries RThe generating function of a sequence is just the FPS with those coefficientsaℕ → R) =Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.aℕ → Rnℕtheorem AlgebraicCombinatorics.FPS.generatingFunction_coeff.{u_1} {R
Type u_1: Type u_1A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`.} [CommRingCommRing.{u} (α : Type u) : Type uA commutative ring is a ring with commutative multiplication.RType u_1] (aℕ → R: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.→ RType u_1) (nℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) : (PowerSeries.coeffPowerSeries.coeff.{u_1} {R : Type u_1} [Semiring R] (n : ℕ) : PowerSeries R →ₗ[R] RThe `n`th coefficient of a formal power series.nℕ) (FPS.generatingFunctionAlgebraicCombinatorics.FPS.generatingFunction.{u_1} {R : Type u_1} (a : ℕ → R) : PowerSeries RThe generating function of a sequence is just the FPS with those coefficientsaℕ → R) =Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.aℕ → Rnℕ
Immediate from the definitions.
Let a,b\in\mathbb{N}, and let n\in\mathbb{N}. Then
\binom{a+b}{n}=\sum_{k=0}^{n}\binom{a}{k}\binom{b}{n-k}.
Lean code for Theorem3.26●1 theorem
Associated Lean declarations
-
theoremdefined in AlgebraicCombinatorics/FPSDefinition.leancomplete
theorem AlgebraicCombinatorics.FPS.vandermonde_nat (a
ℕbℕnℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) : (HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.aℕ+HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.bℕ)HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`..chooseNat.choose : ℕ → ℕ → ℕ`choose n k` is the number of `k`-element subsets in an `n`-element set. Also known as binomial coefficients. For the fact that this is the number of `k`-element-subsets of an `n`-element set, see `Finset.card_powersetCard`.nℕ=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.∑ ijℕ × ℕ∈ Finset.antidiagonalFinset.HasAntidiagonal.antidiagonal.{u_1} {A : Type u_1} {inst✝ : AddMonoid A} [self : Finset.HasAntidiagonal A] : A → Finset (A × A)The antidiagonal of an element `n` is the finset of pairs `(i, j)` such that `i + j = n`.nℕ, aℕ.chooseNat.choose : ℕ → ℕ → ℕ`choose n k` is the number of `k`-element subsets in an `n`-element set. Also known as binomial coefficients. For the fact that this is the number of `k`-element-subsets of an `n`-element set, see `Finset.card_powersetCard`.ijℕ × ℕ.1 *HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.bℕ.chooseNat.choose : ℕ → ℕ → ℕ`choose n k` is the number of `k`-element subsets in an `n`-element set. Also known as binomial coefficients. For the fact that this is the number of `k`-element-subsets of an `n`-element set, see `Finset.card_powersetCard`.ijℕ × ℕ.2theorem AlgebraicCombinatorics.FPS.vandermonde_nat (a
ℕbℕnℕ: ℕNat : TypeThe natural numbers, starting at zero. This type is special-cased by both the kernel and the compiler, and overridden with an efficient implementation. Both use a fast arbitrary-precision arithmetic library (usually [GMP](https://gmplib.org/)); at runtime, `Nat` values that are sufficiently small are unboxed.) : (HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.aℕ+HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`.bℕ)HAdd.hAdd.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HAdd α β γ] : α → β → γ`a + b` computes the sum of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `+` in identifiers is `add`..chooseNat.choose : ℕ → ℕ → ℕ`choose n k` is the number of `k`-element subsets in an `n`-element set. Also known as binomial coefficients. For the fact that this is the number of `k`-element-subsets of an `n`-element set, see `Finset.card_powersetCard`.nℕ=Eq.{u_1} {α : Sort u_1} : α → α → PropThe equality relation. It has one introduction rule, `Eq.refl`. We use `a = b` as notation for `Eq a b`. A fundamental property of equality is that it is an equivalence relation. ``` variable (α : Type) (a b c d : α) variable (hab : a = b) (hcb : c = b) (hcd : c = d) example : a = d := Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd ``` Equality is much more than an equivalence relation, however. It has the important property that every assertion respects the equivalence, in the sense that we can substitute equal expressions without changing the truth value. That is, given `h1 : a = b` and `h2 : p a`, we can construct a proof for `p b` using substitution: `Eq.subst h1 h2`. Example: ``` example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := Eq.subst h1 h2 example (α : Type) (a b : α) (p : α → Prop) (h1 : a = b) (h2 : p a) : p b := h1 ▸ h2 ``` The triangle in the second presentation is a macro built on top of `Eq.subst` and `Eq.symm`, and you can enter it by typing `\t`. For more information: [Equality](https://lean-lang.org/theorem_proving_in_lean4/quantifiers_and_equality.html#equality) Conventions for notations in identifiers: * The recommended spelling of `=` in identifiers is `eq`.∑ ijℕ × ℕ∈ Finset.antidiagonalFinset.HasAntidiagonal.antidiagonal.{u_1} {A : Type u_1} {inst✝ : AddMonoid A} [self : Finset.HasAntidiagonal A] : A → Finset (A × A)The antidiagonal of an element `n` is the finset of pairs `(i, j)` such that `i + j = n`.nℕ, aℕ.chooseNat.choose : ℕ → ℕ → ℕ`choose n k` is the number of `k`-element subsets in an `n`-element set. Also known as binomial coefficients. For the fact that this is the number of `k`-element-subsets of an `n`-element set, see `Finset.card_powersetCard`.ijℕ × ℕ.1 *HMul.hMul.{u, v, w} {α : Type u} {β : Type v} {γ : outParam (Type w)} [self : HMul α β γ] : α → β → γ`a * b` computes the product of `a` and `b`. The meaning of this notation is type-dependent. Conventions for notations in identifiers: * The recommended spelling of `*` in identifiers is `mul`.bℕ.chooseNat.choose : ℕ → ℕ → ℕ`choose n k` is the number of `k`-element subsets in an `n`-element set. Also known as binomial coefficients. For the fact that this is the number of `k`-element-subsets of an `n`-element set, see `Finset.card_powersetCard`.ijℕ × ℕ.2Vandermonde's identity for natural numbers (Proposition prop.binom.vandermonde.NN) Label: eq.prop.binom.vandermonde.NN.eq
Multiply out the identity
\left(1+x\right)^{a+b}=\left(1+x\right)^{a}\left(1+x\right)^{b} using the
binomial formula and compare the coefficient of x^{n} on both sides.
The left side gives \binom{a+b}{n}, and the right side gives
\sum_{k=0}^{n}\binom{a}{k}\binom{b}{n-k} by the product formula for FPSs.