Closed jodavies closed 4 years ago
Does anyone have any opinions on this? It's a trivial change, but I am re-applying it every time I pull new commits from the repo...
I think this is OK to merge; hopefully, no one relies on the old behaviour of fewerstatistics 0
(for the meaning of fewerstatistics 1
)...
@vermaseren
Jos, is it OK to merge? This is backwards-incompatible, in a strict sense. Maybe you know some background of the decision of the behaviour of fewerstatistics 0
.
I guess it is OK. Internally it affects only the printing of the statistics in the WriteStats routine as far as I know. It may change some outputs in the sense that the number of statistics printouts changes. This again could potentially affect scripts that process outputs. But the value 1 is still available and it would probably be rather easy to spot this and also very easy to repair, using grep. Just do not forget to change the manual.
Jos
On 17 Jul 2020, at 12:35, Takahiro Ueda notifications@github.com wrote:
@vermaseren https://github.com/vermaseren Jos, is it OK to merge? This is backwards-incompatible, in a strict sense. Maybe you know some background of the decision of the behaviour of fewerstatistics 0.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vermaseren/form/pull/285#issuecomment-660028895, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJPCEXTF7K3TOP6C3AEMH3R4ASOJANCNFSM4FF4B6LQ.
The document change is also included in this pull request, so I will merge it...
It looks like the change in sort.c
due to this was reverted in the FORM5 code merge (but the manual is intact).
OK, I will re-apply it.
Never print statistics for small buffer sort, if ShortStatsMax is 0
Often I want statistics enabled, but only for the final sort (to see the number of terms in output). For large calculations, one can get many thousands of lines for small-buffer sorts, even with fewerstats set as large as possible.