Dear Richard, 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. Best wishes, Vladimir -- 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 Tue, 7 Jan 2025 23:20:04 +0100, "Richard B. Kreckel" <kreckel@in.terlu.de> said:
RK> Hi, RK> This is now about more than class 'power'... RK> On 1/7/25 12:12 AM, Stefan Weinzierl wrote: >> replacing print_func<print_dflt>(&power::do_print_dflt) by >> print_func<print_context>(&power::do_print) makes sense to me, it >> will treat the class power in the same way as the classes add and >> mul. RK> Even if we fix it this way, the question remains: What purpose RK> does the base class 'print_context' serve other than being an RK> alias for 'print_dflt' - at least for classes 'add', 'mul', RK> 'power', 'numeric', 'symbol', 'pseries', 'lst', 'matrix'? RK> (There's still the same problem for 'clifford', 'spinmetric' and RK> friends that could be fixed as well.) RK> I propose this: 1) Let's modify it such that 'print_context' RK> provides the output of 'print_dflt' for all classes derived from RK> 'basic'. 2) Let's add a 'print_deterministic' subclass which RK> lexicographically sorts the elements of classes where output RK> order normally depends on addresses. Document it with a clear RK> warning that the traversal-order might differ from the output RK> order for this print context type. RK> Comments? (Notably about the first point, in case there is RK> insight about the reasons of having two types 'print_context' RK> and 'print_dflt'.) RK> All my best, -richy. -- Richard B. Kreckel RK> <https://in.terlu.de/~kreckel/>