custom print function for GiNaC::add and GiNaC::mul for deterministic printing
Dear GiNaC guys, first of all: Thanks once more for your powerful library! I have written a neat C code generation for the just-in-time compilation of arbitrary multiphysics finite element equations. The equations are defined in python, can be coupled and combined, and are finally monolithically solved via the library oomph-lib. While code generation is fast, the compilation of the generated code takes some time (~10 seconds for complicated couplings of Navier- Stokes, advection-diffusion, Marangoni flow, mesh node positions for ALE methods, etc.) Now, if the code generation was deterministic, I could check whether the same code has already been compiled in a previous run and skip the compilation in that case. I could also use the tool "ccache" for this. As proposed in the manual, I therefore wanted to write my own print implementation and make sure that in particular "add" and "mul" are written in an e.g. lexiographical order. However, it is a bit problematic since the properties "epvector seq" and "ex overall_coeff" from the class "expairseq" are protected without any public getter functions. Of course, I could iterate over the "::op(index)", but this would convert each "expair" first in an "ex" and I think the "expair" together with the "overall_coeff" is definitely the better way to go. So is there any neat way to access there properties from outside of the class? I understand your decision for using hashes and do not focus on a determinstic order, but in my case, it would definitely help to same some redundant JIT compilation time. Thanks for any help, you are doing a perfect job with GiNaC. Best regards, Christian
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@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@ginac.de CD> https://www.ginac.de/mailman/listinfo/ginac-list
Dear Vladimir, thanks for your answer. I think it will work and this would be my fallback, but it will convert each expair in an ex, which I then have to check again for the sign of the coefficient, or whether it is a negative power in mul, and so on. I just wanted to make sure a priori whether there is a better way directly working on the expairs, but if not, I'll go over the op() of course. Best regards, Christian Am Dienstag, dem 12.10.2021 um 09:25 +0000 schrieb 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
Dear Christian, I see now. It is not difficult to add access methods to elements of expairseq if GiNaC gurus do not see any objections. Another option may be to use expairseq::map() in some way. 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:33:53 +0000, "Diddens, Christian (UT-TNW) via GiNaC-list" <ginac-list@ginac.de> said:
CD> Dear Vladimir, CD> thanks for your answer. CD> I think it will work and this would be my fallback, but it will CD> convert each expair in an ex, which I then have to check again CD> for the sign of the coefficient, or whether it is a negative CD> power in mul, and so on. CD> I just wanted to make sure a priori whether there is a better CD> way directly working on the expairs, but if not, I'll go over CD> the op() of course. CD> Best regards, CD> Christian CD> Am Dienstag, dem 12.10.2021 um 09:25 +0000 schrieb Vladimir CD> 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
Following the previous discussion I am attaching just in case a trivial patch which opens an access to expairseq elements. -- 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:55:57 +0000, "Vladimir V. Kisil" <V.Kisil@leeds.ac.uk> said:
VVK> Dear Christian, VVK> I see now. It is not difficult to add access methods to VVK> elements of expairseq if GiNaC gurus do not see any objections. VVK> Another option may be to use expairseq::map() in some way. VVK> Best wishes, Vladimir -- Vladimir V. Kisil VVK> http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius VVK> Maps https://doi.org/10.1142/p835 Soft: Geometry of cycles VVK> http://moebinv.sourceforge.net/ Jupyter notebooks: VVK> https://github.com/vvkisil/MoebInv-notebooks
On Tue, 12 Oct 2021 09:33:53 +0000, "Diddens, Christian (UT-TNW) VVK> via GiNaC-list" <ginac-list@ginac.de> said:
CD> Dear Vladimir, CD> thanks for your answer. CD> I think it will work and this would be my fallback, but it will CD> convert each expair in an ex, which I then have to check again CD> for the sign of the coefficient, or whether it is a negative CD> power in mul, and so on. CD> I just wanted to make sure a priori whether there is a better CD> way directly working on the expairs, but if not, I'll go over CD> the op() of course. CD> Best regards, CD> Christian CD> Am Dienstag, dem 12.10.2021 um 09:25 +0000 schrieb Vladimir CD> 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
Dear Vladimir, thanks! I was also about to do this, but I am not sure whether the headers are compatible with the compiled binaries afterwards. After all, my code is used within our group in Linux, Mac and Windows and I don't want to modify GiNaC since I am currently linking against the repository binaries for Linux, the homebrew package for Mac and the compiled binaries for Windows you kindly sent me some time ago. However, in the worst case I will add the modified GiNaC to my code and compile it along with my code on all platforms. Best regards, Christian Am Dienstag, dem 12.10.2021 um 10:20 +0000 schrieb Vladimir V. Kisil:
Following the previous discussion I am attaching just in case a trivial patch which opens an access to expairseq elements.
On Tue, 12 Oct 2021 11:24:19 +0000, "Diddens, Christian (UT-TNW) via GiNaC-list" <ginac-list@ginac.de> said: CD> the compiled binaries for Windows you kindly sent me some time ago.
By the way, here is Windows library update for GiNaC 1.8.1: https://leeds365-my.sharepoint.com/:f:/g/personal/pmtvk_leeds_ac_uk/EtzgPTKr... -- 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
participants (2)
-
Diddens, Christian (UT-TNW)
-
Vladimir V. Kisil