[GiNaC-list] custom print function for GiNaC::add and GiNaC::mul for deterministic printing

[Vladimir V. Kisil]

	Dear Christian,

	Just a quick question: why does expairseq::op() method
  (inherited by sums and muls, I think) will not work for you?

  Best wishes,
  Vladimir
-- 
Vladimir V. Kisil                 http://www.maths.leeds.ac.uk/~kisilv/
  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/MoebInv-notebooks
>>>>> On Tue, 12 Oct 2021 09:10:12 +0000, "Diddens, Christian (UT-TNW) via GiNaC-list" <ginac-list at ginac.de> said:

    CD> Dear GiNaC guys,

    CD> first of all: Thanks once more for your powerful library!

    CD> I have written a neat C code generation for the just-in-time
    CD> compilation of arbitrary multiphysics finite element
    CD> equations. The equations are defined in python, can be coupled
    CD> and combined, and are finally monolithically solved via the
    CD> library oomph-lib.

    CD> While code generation is fast, the compilation of the generated
    CD> code takes some time (~10 seconds for complicated couplings of
    CD> Navier- Stokes, advection-diffusion, Marangoni flow, mesh node
    CD> positions for ALE methods, etc.)

    CD> Now, if the code generation was deterministic, I could check
    CD> whether the same code has already been compiled in a previous
    CD> run and skip the compilation in that case. I could also use the
    CD> tool "ccache" for this.

    CD> As proposed in the manual, I therefore wanted to write my own
    CD> print implementation and make sure that in particular "add" and
    CD> "mul" are written in an e.g. lexiographical order.  However, it
    CD> is a bit problematic since the properties "epvector seq" and "ex
    CD> overall_coeff" from the class "expairseq" are protected without
    CD> any public getter functions.

    CD> Of course, I could iterate over the "::op(index)", but this
    CD> would convert each "expair" first in an "ex" and I think the
    CD> "expair" together with the "overall_coeff" is definitely the
    CD> better way to go.

    CD> So is there any neat way to access there properties from outside
    CD> of the class?  I understand your decision for using hashes and
    CD> do not focus on a determinstic order, but in my case, it would
    CD> definitely help to same some redundant JIT compilation time.

    CD> Thanks for any help, you are doing a perfect job with GiNaC.

    CD> Best regards,

    CD> Christian _______________________________________________
    CD> GiNaC-list mailing list GiNaC-list at ginac.de
    CD> https://www.ginac.de/mailman/listinfo/ginac-list