On Sun, 12 Jan 2025 10:20:43 +0000, "Vladimir V. Kisil" <V.Kisil@leeds.ac.uk> said:
VVK> Yes, Richard, I see your point. Yet, one printing context, which may also benefit from a lexicographic ordering vs random memory allocation, is LaTeX... -- Vladimir V. Kisil http://v-v-kisil.scienceontheweb.net Book: Geometry of Mobius Maps https://doi.org/10.1142/p835 Soft: Geometry of cycles http://moebinv.sourceforge.net/ Jupyter notebooks: https://github.com/vvkisil?tab=repositories
On Sat, 11 Jan 2025 22:01:48 +0100, "Richard B. Kreckel" VVK> <kreckel@in.terlu.de> said:
RK> Dear Vladimir, RK> On 1/8/25 11:36 AM, Vladimir V. Kisil via GiNaC-devel wrote: >>> Your proposal seems to be sensible to me. As a variation of it: >>> can "print_deterministic" be just a flag for any declared >>> printing method? It may be not so useful in outputs for C or >>> Python, but printing a tree in a deterministic way may be an >>> advantage. RK> That goes beyond my suggestion and I'm not sure it is possible. RK> Anyway, we must be very careful with 'faking' a print order for RK> the purpose of reproducibility. It is a double-edged sword: If RK> you think that 'e' is 'a-b' you expect 'e.op(0)' to be 'a' and RK> 'e.op(1)' to be '-b' but that is not going to be fulfilled by RK> deterministic print orders. I think this suggests that the print RK> order 'print_tree' should remain as it is. After all, it is RK> mainly for debugging purposes. RK> By the same token, I think that the print order of ginsh should RK> remain as it is - non-deterministic - because ginsh offers the RK> 'op(e,n)' built-in function. Making ginsh's print only order RK> differ from that of 'op' would be too confusing. RK> All my best, -richy. -- Richard B. Kreckel