[GiNaC-devel] printing of class power

[Vladimir V. Kisil]

>>>>> On Sun, 12 Jan 2025 10:20:43 +0000, "Vladimir V. Kisil" <V.Kisil at 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 at 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