math-comp / mcb

Mathematical Components (the Book)

This is the "Mathematical Components" book.

Building

To build the book using Nix, run

# without flakes, check out the repo first
$ NIXPKGS_ALLOW_UNFREE=1 nix-build
# with flakes
$ NIXPKGS_ALLOW_UNFREE=1 nix build github:math-comp/mcb --impure

Alternatively you may fetch the latest artifact produced by the CI for the master branch here.

The tex/ directory contains the sources. TexLive 2014, 2021 is known to work.

The coq/ directory contains snippets corresponding to the chapters of the book.

The docs/ directory contains the website of the book.

The artwork/ directory contains the graphics used in the book.

Homepage

Link to the homepage of the book

mcb's Issues

Inconsistent Bibliography Denotation

I downloaded the book on this site : https://math-comp.github.io/mcb/ (last update Sun Aug 5 09:38:42 CEST 2018).
In the text, the bibliographic references appears with a number between square brackets, like [24] whereas in the Bibliography section it appears with first letters of the authors and year like [BG01].

"Eval compute in" vs "Compute" ?

Eval compute in is introduced in chapter 1. In my opinion, the syntax is bit verbose for the newcomer and also does not look very much like About, Check, and Print. There is a simpler alternative: Compute, which is an alias of Eval vm_compute in.

What do you think of using Compute throughout the book?

(Eval hnf in could be explained a bit later to make things a bit smoother at the beginning)

\cite[chapter]{Coq:manual} are all wrong

since the manual has no more section numbers

Example in chapter 2, sect. 2.3.3

The example starting on line 1435 needs some corrections.

1. Lemma example m p : prime p -> p %| m `! + 1 -> m < p. suddenly turns into Lemma example m p : prime p -> p %| m `! + 1 -> ~~ (p <= m)., then it reverts to the original version.
2. The text mentions contraLR lemma, but contraL appears instead.

Also, could the real dvdn_fact lemma be used instead of a wrapper defined in the text?

• text: Lemma dvdn_fact m n : 0 < m -> m ≤ n → m %| n`!.
• library: Lemma dvdn_fact m n : 0 < m ≤ n → m %| n`!.

remove exercises

move them to a companion teaching material

Ch. 6: (n : nat) + (i : ’I_7) can't be smaller than 7

Integers and integers smaller than 7 are interchangeable data: if (n : nat) and (i : ’I_7) one can clearly add n to i, and eventually show that the sum is still smaller than 7.

The last part of the sentence should probably be removed, since the paragraph mentions (i+n %| 7).

give chapters to reviewers

Book uses left quote instead of backtick.

So far when reading the book I have only noticed this issue for the factorial notation. The book uses '! instead of `! .
Looking through the latex source it's that annoying thing where latex compiles the back-tick symbol to left quote. The only ideas I have for fixing this issue is either explicitly say "back-tick" in the text or to import the package textcomp and then use \textasciigrave instead of `.

Typos in the first pages

It is a real pleasure to read this clear text about Coq. If it may help
here are some typos and suggestions about the version draft 0, August 27,
2016. Capital letters (such as S in the first line below) signal something to
add or remove, depending on what is in the book.

0.1.2: aN librarian

Page 13: an operation on an object -> an operation on one object

Page 14: n + 2 -> n + 1 (twice)

Page 18 [remove space], implyb -> , AND implyb

Page 20: the immediate subterm of n AND the computation proceeds

Page 20: we need to revert to the “match .. with .. end” syntax.'' -> it is more convenient/simpler to ..'', because one can also use nested
'if .. then .. else' constructs.

Page 20: onE can prefix the fiRst pattern

Page 21: can also containS

Page 21: ``When computing with a natural number, all the pattern matching rules
are tried successively against this number.'' More important is that patterns
may 'overlap' (i.e. share matching cases) and that the result is given by
the first one that matches (in the order they are written).

Page 21: u.+1.+1.+.1 -> u.+1.+1.+1

Page 21: showing a syntactic facility to scrutinized -> showing a syntactic
facility to scrutinize

Page 22: Recursion for integers -> Recursion for natural numbers

Page 22: In this line, -> In these lines,

Page 22: the Coq systems -> the Coq system

Page 24: this chapterS

Page 24: Exchange n and m in ``(m > n) is only accepted in input and is always
printed as (n < m).'' for correspondence with the names in the block above.

That's all for today. Hope it may help.

Comment on the use of `Definition d := Eval hnf in [expression]`

My understanding is that this provides definition-time partial evaluation and that using the specialised programs is more efficient but it would be nice to see this pattern not just used but also commented upon.

§5.6: case: (x1 =P x2) pushes x1 <> x2 instead of x1 != x2 into the second subgoal

the branch corresponding to \C{ReflectT} has the hypothesis \C{x1 = x2} and the branch corrsponding to \C{ReflectF} has its negation \C{x1 != x2}.

Besides the typo "corrsponding", the negation of x1 = x2 is actually x1 <> x2.
Because the notation <> hasn't been mentioned so far, some additional explanation would be necessary.

Also, the line below in the subsequent example does not type check because undup_uniq ss is not of type bool.

Check (ss != [::]) && s1 \in ss && undup_uniq ss.

rename chapter 5

something like "boolean reflection" and rework the intro

§3.2.4: Line 3 in example "stamps" uses unexplained syntax

I'm talking of this:
elim: n {-2}n (leqnn n) =>[|n IHn]; first by case.
I have really no idea what is happening between the elim and the => here. Apparently it magically transforms the goal into a version of it such that inducting over the latter is equivalent to strongly inducting over the former; at least the leqnn n is definitely relevant for that. But what is the {-2}n achieving? (I understand that {-2} means something like "all except for the 2nd occurrence" -- which should probably be explained though --, but what exactly is being done here? Generally, what does elim: do when given several arguments? What order are they traversed, and what is done to them?

(I can get through the example if I replace the line quoted above by
have: forall n0 : nat, n0 <= n -> 12 <= n0 -> exists s4 s5 : nat, s4 * 4 + s5 * 5 = n0; last first.
move=> Strong_Version. apply (Strong_Version n (leqnn n)).
elim: n => [|n IHn]; first by case.
But this is ugly...)

Sect. 3.1.2: "isT : true is a valid proof of (0 < n.+1)" is a bit misleading

The term (isT : true) is a valid proof of (0 < n.+1), as well as a proof of (0 != p.+1).

The section should probably remind the reader that isT has type is_true true because of the coercion mechanism.

Sect. 3.2.4: stamps lemma

Chances are this is not really an issue. It's just an alternative proof for the stamps lemma:

Lemma addnBAC m n p : n <= m -> n <= p -> (m - n) + p = m + (p - n).
Proof. by move=> le_nm le_np; rewrite addnC !addnBA // addnC. Qed.

Lemma stamps n : 12 <= n -> exists s4 s5, s4 * 4 + s5 * 5 = n.
Proof.
rewrite {2}(divn_eq n 4) => gt11; exists (n %/4 - n %% 4), (n %% 4).
rewrite mulnBl addnBAC -?mulnBr ?muln1 ?leq_mul //.
by apply: (@leq_trans _ (n %% 4) _ (@ltn_pmod n 4 isT) (leq_div2r 4 gt11)).
Qed.

This approach does not use strong induction, hence it cannot be used for the same purposes as the original proof. Feel free to use this solution in any way you find suitable -- I'm also fine with closing this "issue" since I'm putting it here in case the proof can be useful to anyone.

Sect. 1.2 Data types, first examples: confusing paragraphs

The following two paragraphs are confusing.

mcb/tex/chProgramming.tex

Line 621 in a3b08e8

In \Coq{}, such languages are represented using a \emph{data type},

In \Coq{}, such languages are represented using a \emph{data type},
whose definition provides in a first single declaration the name of the
type and the constructors, plus some rules on how to define maps on
these data types or prove theorems about their elements.  The other
operations are then derived from these rules.

The first single declarations of data types are introduced by the means of
\emph{inductive type definitions}.
One can then explicitly define more operations on the elements of
the type by describing how they compute on a given argument in the
type using a case analaysis or a recursive definition on the
shape of this argument.

Shouldn't those be fused together?

Building instructions

Instructions for building the book from source, for typechecking the Coq code from the book, etc.

Missing space in §1.1.2

There's a missing space after "the" in

This response actually reads nat -> (nat -> nat), as the-> symbol ...

Improve tools for spellchecking

See the suggestions by @mdnahas in the (merged) #11.

Tiny grammar nit (§1.1.1)

In section 1.1.1 (I'm reading from the top!), this reads oddly:

As expected, it makes little sense to compute the addition between a function and 1.

Maybe something like this would be better?

As expected, it makes little sense to compute the sum of a function and 1.

I don't think that "addition between" sounds right.

Chapter 8 & 9 are empty

I don't know if they're a work in progress or if there really is an error, but chapter 8 and chapter 9 of the pdf appear empty.

add note to section on finite function

they are now defined with ad-hoc inductive so that they are not problematic with positivity checking

Typos and mistakes

Page 41: line 6 of Exercise 1 has = true : bool as an output, should have = false : bool instead

Page 46: "swell-formed"?

Page 56: "back yo our example" should be "back to our example"

Page 63: uses of "contraL" should be "contraLR"

Page 64: "apply: prime_gt0" doesn't work, but "rewrite prime_gt0" does.

Page 106: "contraxposition"

Add a section about the totality of functions

The main message of the discussion on the definition of subn seems to be to comment on the impact of the necessary totality of functions. This should be promoted as a section and include the stuff about odflt and the like which are now in containers.

§2.4: the main goal actually mentions the “divides” predicate

The 5th paragraph in Section 2.4 says:

In fact, optionally rewriting with dvdn_fact on all goals affects only the side condition, since the main goal mentions no “divides” predicate.

But the main goal at this stage below actually mentions the “divides” predicate:

  m, p : nat
  prime_p : prime p
  leq_p_m : p <= m
  ============================
  ~~ (p %| 1)

§2.3.1: explanation of "commutative" not updated

The type of "commutative" is made consistent with the actual library definition with the commit https://github.com/math-comp/mcb/commit/9f9e7f0b8fa396dfc6922b8be77fbd4fa84c1a12 by taking the type parameters S and T rather than just T. But the text after the Coq code example named "aboutcomm" in §2.3.1 still explains the older version.

remove ex from ch 6

book structure in intro is outdated

part 1 also covers formalization techniques
part 2 title should be more specific, it is about inference and organizing the library

Sect. 1.3.3 Option and pair data types: pair type is called prod in Coq

mcb/tex/chProgramming.tex

Line 1676 in abd9892

\begin{coq}{name=pair}{}

Inductive pair (A B : Type) : Type := mk_pair (a : A) (b : B).
Notation "( a , b )" := (mk_pair a b).
Notation "A * B" := (pair A B).

I think the book should at least mention that in Coq the book'spair is actually prod and mk_pair is pair :)

But perhaps it would be better not to introduce those aliases in the first place and reuse the standard definition?

The simplify_me lemma in sect 2.4 won't compile

Lemma simplify_me : size [::] = 0. won't compile because we can't infer the type of the elements of the empty sequence.

3.4 conversion rule is not the standard one

it is the implemented on, eg the one you would write in a syntax directed system, and not in a declarative one... both are fine to me but it should be clarified

§2.3.1: (rel T) explained, but no longer used

In §2.3.1, (R: rel T) is declared in the Coq code example named "predicators", and (rel T) is explained in the following text. But R is actually no longer used in this example. Its only use (transitive R) was removed by the commit https://github.com/math-comp/mcb/commit/298806cc5019a13efc94282e7c6763b49d5f6dc3.

§1.3p31: explanation of n-ary operations uses different separation symbol for the text and the example

Paragraph §1.3 on Containers describes

a general pattern for n-ary operations obtained by the (right-associative) iteration of a single binary one.

It goes on to explain that a , (comma) is used to separate elements but for the last which will be separated by a & (ampersand). The example shown a few lines later demonstrates a different usage. In particular

[:: 1; 2; 3 & l]

Although this use is explained a little further down,seq nat is nil-terminated and these containers follows the convention shown above, it is kind of distracting.

Introduce first class citizen before using it

In the book, it is said that 'types are first class citizen', without really explaining what it is. It might confused the 'mathematically inclined reader'.

Conventions: advice vs tricky details

This is how it gets rendered for me:

Are both of these supposed to have the same symbol (circled R)?

stars (signalling difficulty) are not very useful and infequent

we should just drop them and eventually warn the reader that the current section is technical and can be skipped.

issues in chapter 1

In section sec:othercontainers, 'pointed version of A' is a bit sudden, since 'pointed' is not defined.
Also, the sentence 'This may be a drawback, consequence of representing tuples as nested pairs.' reads awkwardly.

Question on the Cheatsheet

Let's say I want to prove the following silly theorem

  Theorem test (x y : nat) : if x < y then x < S y else true.
  Proof.

I would do use the case tactic to destruct (x < y). However, to prove the if branch, I need to remember the equation x < y = true.

Hence, I would start my proof this way

  case eqxy: (x < y).

But there is no mention on the cheat sheet whether it is possible to remember this equation using the case tactic. I know it is not possible to put everything on a cheat sheet, but such thing happens often when I am proving things. However, since I am not completely used to the ssreflect language, maybe there is a more idiomatic way to achieve the same goal.

Some remarks on Chapter 7

Hi, I recently had a closer look at Chapter 7, and here are a few subtle things I stumbled across:

• Sect. 7.1: It took me quite a while (and a lot of Find/Check/Print and looking at the source files) to find out that ComRingMixin, even though it takes a proof of commutativity, only constructs a generic ring mixin (using commutativity to obtain the right identity/distribution laws). This was made all the more confusing though the comment that for commutative rings no mixin definition is necessary. Maybe add a sentence to explain that.
• Sect 7.3: Here class is just the explicit definition of the second component of the Section variable cT : type. This may be bordering on being pedantic, but to me this sounds like the (given) section variable being defined. How about: Here, class is just a short name for the second component ... ?
  Also, matching the presented code snipped against the actual code in choice.v reveals that the base, mixin and sort coercions are only defined later in the Exports module. Incidentally, the sort coercion is needed for class to type check and the local coercion introduced in choice.v for this purpose is suppressed in the html documentation. These discrepancies and the hidden local coercion make it hard to follow the provided patterns.
• Sect 7.3: I am not sure strict identities is the best terminology to refer to equality axioms. In particular, since that terminology is not used elsewhere. Moreover understanding the example associative add requires looking up/knowing the definition of associative, which is about 100 pages away.
• Sect 7.5: Remark how... I'm pretty sure you want the reader to note this and not make a remark (Well, I now made a remark. 😄 ). Similarly, the last paragraph should maybe start with More generally, ...

That being said, the chapter helped me to better understand the the subtleties of packaging classes. 👍

5.4 (notational aspects...) is out of place and has dangling refs

does not fit well ch5, Posz is out of the scope of the book, still some room for notational aspects of specs. We should talk about that later once we have 6.10 at hand and try to give some guiding principles to understand/craft notations in MC

Difficulty with using references to Coq manual

References to numbered sections and chapters of the Coq manual are difficult to interpret/follow-up since it appears that the reference manual is now web-only without a PDF version available.

overlapping margin notes on p. 25

There seems to be 2 margin notes on top of each other at the bottom of p. 25 in the version linked from https://math-comp.github.io/mcb/book.pdf

Web ver?

Hi,
Do you guys have any plan to host an HTML version like SF and CPDT?
That would be awesome.

Suggestions on Chap. 2

Let me know if I should split this into multiple issues!

Page number may be different; here I use the page numbers from the pdf compiled from source at the latest commit.

p.57, S2.2:

Indeed it is a good practice to get rid of the easiest subgoals as early as possible

Why? Do they cost anything?

This proof script can actually be made more compact...

Why do people like to make Coq scripts compact? Very often when I try to understand a proof I have to expand it myself, so to interact with the tactics and see the intermediate results.

simplify switch

Why not just add // to every introduction by default?

p.64

apply: tactic

Chapter 3 points out ssr's apply: (with a colon) differs from Coq's apply (without). Might worth pointing out it here?

Hint Resolve

Why not tag every lemma with this?

p. 65

move

Chapter 3 makes clear why one needs to move the A in A -> B to the context, but from an implementation perspective. How does this correspond to pen and paper proofs? Why do I need to move the a in \forall a, e to perform a rewrite in e?

§4.1.3: Lemma example uses andP view, which won't work with current definition of reflect

Up until §4.1.3 every lemma can be proved using the temporary definition of reflect from §4.1.1. I think to avoid confusion, the book should mention that we need "real" reflect to use move=> lekn/andP..

Explain earlier how to turn an argument as implicit

This should come just after the definition of type seq. And include a comment on the output of the About command.

Remove marginnotes

remove part 3 (synopsis)

§3.1.2, p. 81, footnote 2: a typo?

The footnote starts with "In veritas". Is this a typo?

Sect. 1.3.3 Option and pair data types: introduce irrefutable pattern-matching?

The section defines fst function as follows:

Definition fst A B (p : pair A B) :=
  match p with mk_pair x _ => x end.

This might be an opportunity to introduce irrefutable pattern-matching construction:

Definition fst A B (p : A * B) : A :=
  let: (a, _) := p in a.

(probably after the original more verbose version)

Sect. 1.3.4 shows this construction, but still it might make sense to introduce it earlier.