[GiNaC-devel] printing of class power

[Vladimir V. Kisil]

        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 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
    RK> <https://in.terlu.de/~kreckel/>
    RK> _______________________________________________ GiNaC-devel
    RK> mailing list GiNaC-devel at ginac.de
    RK> https://www.ginac.de/mailman/listinfo/ginac-devel