`Learning.rewardByCountUntil_apply_of_pullCount_le`🔗

Lemma

From the authors

If action a was pulled at most m times before time t, then the entry (a, m) of rewardByCountUntil A R' t ω is the entry (m + 1, a) of the auxiliary array.

Types

𝓐 : Type u_2DecidableEq 𝓐
R : Type u_3
Ω : Type u_4

Given

A : ℕ → Ω → 𝓐
R' : ℕ → Ω → R
a : 𝓐
m : ℕ
t : ℕ
ω : Ω × (ℕ → 𝓐 → R)

Assuming

h : pullCount A a t ω.1 ≤ m

Then

rewardByCountUntil A R' t ω (a, m) = ω.2 (m + 1) a

DecidableEq : 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 : α`.

Nat : Type

The 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.

Prod : 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`.

LE.le : {α : Type u} → [self : LE α] → α → α → Prop

The less-equal relation: `x ≤ y` 

Conventions for notations in identifiers:

 * The recommended spelling of `≤` in identifiers is `le`.

Learning.pullCount : {𝓐 : Type u_2} → {Ω : Type u_4} → [DecidableEq 𝓐] → (ℕ → Ω → 𝓐) → 𝓐 → ℕ → Ω → ℕ

Number of times action `a` was chosen up to time `t` (excluding `t`).

Go to its page

Eq : {α : Sort u_1} → α → α → Prop

The 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`.

Learning.rewardByCountUntil : {𝓐 : Type u_2} →
  {R : Type u_3} → {Ω : Type u_4} → [DecidableEq 𝓐] → (ℕ → Ω → 𝓐) → (ℕ → Ω → R) → ℕ → Ω × (ℕ → 𝓐 → R) → 𝓐 × ℕ → R

Array of rewards by count, truncated at time `t`: the entry `(a, m)` is the reward received at
the `(m + 1)`-th pull of action `a` if that pull happened before time `t`, and the entry
`(m + 1, a)` of the auxiliary array `ω.2` otherwise.

This is an auxiliary definition used to prove results about the distribution of `rewardByCount`.

It is defined recursively: at time `t`, the
entry `(A t, pullCount A (A t) t)` is replaced by the reward `R' t`.
See `rewardByCountUntil_apply_of_lt_pullCount` and `rewardByCountUntil_apply_of_pullCount_le`.

Go to its page

Prod.mk : {α : Type u} → {β : Type v} → α → β → α × β

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`.

HAdd.hAdd : {α : 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`.

Code

lemma rewardByCountUntil_apply_of_pullCount_le (h : pullCount A a t ω.1 ≤ m) :
    rewardByCountUntil A R' t ω (a, m) = ω.2 (m + 1) a

Proof

by
  induction t with
  | zero => rfl
  | succ t ih =>
    rw [rewardByCountUntil_add_one, Function.update_of_ne,
      ih ((pullCount_mono a (Nat.le_succ t) _).trans h)]
    intro hp
    obtain ⟨rfl, hm⟩ := Prod.mk.inj hp
    rw [pullCount_action_eq_pullCount_add_one] at h
    omega

New in v4.34.0-rc2-31-g21d7e67 (2026-09-07), and its meaning has not changed since.

Self-contained, with its dependencies inlined and proofs replaced by sorry: download the raw file · open it in the Lean web editor.

Dependency graph

Audit surface: 2 project declarations, 25 external constants

✓ Proved: no sorry anywhere in its closure

This is the tool's own reading of one build's recorded axioms, and it is not robust against an author who wants it to pass. Checking meant to be relied on should go through Comparator, which replays the proof through the kernel from an export against an explicit list of permitted axioms.

Learning.rewardByCountUntil_apply_of_pullCount_le🔗

`Learning.rewardByCountUntil_apply_of_pullCount_le`🔗