Skip to content

Conversation

@cmlsharp
Copy link
Contributor

@cmlsharp cmlsharp commented Dec 31, 2025

This PR adds the Array equivalents of List.scan{l,r,L,R}. It was originally part of #1581.

  • This PR provides both reference and efficient versions of Array.scanlM and Array.scanrM, and then defines Array.scanl and Array.scanr in terms of them. This is identical to how the standard library currently handles Array.fold*.
  • Unlike the standard library, this PR attempts to make minimal use of unsafe in the implementations of the efficient versions. It defines an assumption (as Array.size_fits_usize) as well as an unsafe proof of this assumption (as Array.unsafe_size_fits_usize). These are currently public definitions. I could make them private, but they seem useful for writing other 'efficient' array functions.
  • Array.scanlM is proven to be equivalent to its efficient implementation under the assumption that Array.size_fits_usize holds. The efficient version of Array.scanrM additionally uses this assumption when constructing the proofs for the bounds checks.
  • I do not have a proof that the efficient version of Array.scanrM is equivalent to its efficient version under Array.size_fits_usize. It should be possible, but the structure of these two implementations differ more, so the proof is more difficult. With Array.scanlM the only difference between the implementations was the use of USize or Nat for the index, whereas the Array.scanrM reference implementation builds the array, then reverses it and the efficient implementation iterates over the array in reverse.

@github-actions github-actions bot added the awaiting-review This PR is ready for review; the author thinks it is ready to be merged. label Dec 31, 2025
@cmlsharp
Copy link
Contributor Author

The simpNF linter is not a fan of lemmas that do not specify the optional arguments (in particular start and stop). I did not manually write these because the standard library lemmas for Array.foldl/Array.foldr do not do this and I think it kind of clutters up the lemma definition. Should I make this change?

@cmlsharp
Copy link
Contributor Author

cmlsharp commented Jan 5, 2026

WIP

@github-actions github-actions bot added WIP work in progress and removed awaiting-review This PR is ready for review; the author thinks it is ready to be merged. labels Jan 5, 2026
@leanprover-community-mathlib4-bot leanprover-community-mathlib4-bot added the merge-conflict This PR has merge conflicts with the `main` branch which must be resolved by the author. label Jan 6, 2026
@cmlsharp
Copy link
Contributor Author

cmlsharp commented Jan 7, 2026

awaiting-review

@github-actions github-actions bot removed the WIP work in progress label Jan 7, 2026
@github-actions github-actions bot added the awaiting-review This PR is ready for review; the author thinks it is ready to be merged. label Jan 7, 2026
@cmlsharp
Copy link
Contributor Author

cmlsharp commented Jan 7, 2026

(as mentioned above this is failing ci currently because the simpNF seems to want me to manually specify the start and stop default arguments on the LHS of every theorem. I'm unsure if this lint should somehow be disabled, or whether it is preferable to include these default args in every theorem statement)

@leanprover-community-mathlib4-bot leanprover-community-mathlib4-bot removed the merge-conflict This PR has merge conflicts with the `main` branch which must be resolved by the author. label Jan 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

awaiting-review This PR is ready for review; the author thinks it is ready to be merged.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants