sage -t --optional=internet only runs the internet tests, and not any of the tests that are run by default. You almost always want sage -t --optional=sage,internet, and similar for other optional packages. IMHO this should be spelled out in more detail as it is a frequent cause for confusion.

sage -t --optional=internet only runs the internet tests, and not any of the tests that are run by default. You almost always want sage -t --optional=sage,internet, and similar for other optional packages.

True. Actually, I never ran --optional without having 'sage' inside. Should we change that instead ? I can't think of any good reason for this kind of behaviour, as it does create confusion.

I think the remark (rounding error/floating point arithmetic) is important enough that it should be clarified and expanded further: what about (due to system-dependent floating point arithmetic or math libraries or non-deterministic algorithms).

The sentence Neither of this applies to files or directories which are explicitly given as command line arguments: those are always tested. should be outside the list, since it refers both to files and directories. It should not be just in the "directory" item.

I implemented all changes that you asked. I only omitted "math libraries" from
(due to system-dependent floating point arithmetic or math libraries or non-deterministic algorithms)

Because in my understanding, most of what Sage contains is a math library. Fortunately what causes problems in the third-party math librarires that we use is precisely floating-point airethmetic or non-deterministic algorithms, so that's fine.

What about the --optional=sage,keyword? The rationale was that you might be able to speed up testing by only running the optional tests, but in practice that pretty much never works (since some intermediate steps tend to not have the #optional tag) and I've never used it. IMHO: Either document it clearly or change the behavior.

Maybe Karl-Dieter wants to give it a read since he's the only native English speaker...

What about the --optional=sage,keyword? The rationale was that you might be able to speed up testing by only running the optional tests, but in practice that pretty much never works (since some intermediate steps tend to not have the #optional tag) and I've never used it. IMHO: Either document it clearly or change the behavior.

I wouldn't change the behavior now, but I agree that it should be documented.

What about the --optional=sage,keyword? The rationale was that you might be able to speed up testing by only running the optional tests, but in practice that pretty much never works (since some intermediate steps tend to not have the #optional tag) and I've never used it. IMHO: Either document it clearly or change the behavior.

I agree that this should be documented.

Maybe Karl-Dieter wants to give it a read since he's the only native English speaker...

The English looks okay to me.

Two more suggestions: we should define relative and absolute tolerance, or at least give a link to a definition. Also, maybe we should emphasize that the "32-bit" and "64-bit" flags go on the output lines, not the input lines the way the other flags do. (Either before or after the example: "Note that unlike the other flags, these keywords go on the *output* lines, not the input lines.)

I think that it is sufficient for the moment, especially since we all seem to agree that this behaviour should be changed so that 'sage' is always included in --optional=<a list>.

A line flagged with ``optional - keyword``, it is not tested: remove ", it"

Done.

I really think that it should be involves since "representation" is singular.

Done.

Also, maybe we should emphasize that the "32-bit" and "64-bit" flags go on the output lines.

Done

From the look of your comments I have no idea if you consider that this ticket can be switched to positive_review yet, but I would really appreciate it if you could make all your comments at once, next time. I have already pushed 6 different review commits here, and that is much more work than implementing at once all of the reviewer's comments.

I would really appreciate it if you could make all your comments at once, next time. I have already pushed 6 different review commits here, and that is much more work than implementing at once all of the reviewer's comments.

Don't forget that there was a lot of confusion about the tolerance stuff... I think that's mainly what caused the many commits. Also, it's not also always to give all reviewer comments at once: when there are major mistakes, I find it harder to concentrate on spelling errors. Also, sometimes I have comments about the review commits...

I was also busy doing other things these days, so I didn't have the time to make those review commits myself like I would usually do.