Suggestions for Chapter 6: Parameters

[leonlan]

• [x] Style: I think it's a bit too much to list all the (sub-)solvers used in https://d-krupke.github.io/cpsat-primer/05_parameters.html#parallelization. The current layout makes it hard to read and it is a lot of information that might not be relevant to readers. Is there a reference that we can refer to instead, or can we think of a better way of visualizing this as a table?

• [ ] Content: I have seem multiple times Laurent Perron mention that it is really recommended to use OR-Tools with 8 cores, or even 16 cores. Should we mention this somewhere in the parallelization section as well?

• [x] Content: We could also mention what the default setting of the solver is regarding parallelization, which is to use all available cores by default right?

• [x] Structure: There are three sections that are not strictly "parameters" (exporting model, adding assumptions, adding hints). The section then ends with "decision strategy", which is a parameter again. I don't think this is problematic but I noticed it.

• [x] Structure: I think it's easier to start with hints first and then discuss assumptions. Hints are similar to warm-starts, which most readers understand. Assumptions are more niche because they only apply to boolean variables.

• [x] Content: The assumptions section starts begin with

  "Often, you may need to explore the impact of forcing certain variables to specific values."

  This is a bit deceptive because assumptions can only force boolean variables. In combination with the restructuring point above I suggest 1) discussing parameter "fix_variables_to_their_hinted_value" in the hints section, which does practically the same 2) rewriting the assumptions section to emphasize that this is only for fixing bools.

• [ ] New content: This section starts with a brief mention of protobufs. This was a completely new concept to me when I started reading into OR-Tools but it's a common practice by Google and similar ideas apply to other software (e.g., intermediate data representation for modeling APIs). Perhaps we can add a section to the advanced topics on protobufs? I can make a separate issue for that.