Yes, Richard, I see your point. -- 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" <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 RK> <https://in.terlu.de/~kreckel/> RK> _______________________________________________ GiNaC-devel RK> mailing list GiNaC-devel@ginac.de RK> https://www.ginac.de/mailman/listinfo/ginac-devel