Adding python support to GiNaC
Hi! I have been working on the python interface to GiNaC. It is quite usable already and I have tested it in many problems. However, it would be great if some python specific changes that I had to do in GiNaC, could be added to GiNaC. These changes include mostly printing expressions. Earlier I used hooks from GiNaC archive features to get desired output for python, but it was _very_ slow compared to the native GiNaC print hooks. So, please find a patch attached that adds two new print_context classes, print_python and print_python_repr, with the corresponding additions to print methods of the basic classes. The patch includes also the following change in the idx::print method for print_latex context: `a.b' becomes `a_{b}' if b is covariant, `a^{b}', otherwise (you can ignore it if you don't like it). This patch is against GiNaC-1.0.1. I can make it also against the latest GiNaC in CVS. Let me know if needed. Thanks, Pearu
Hi there, On Tue, 18 Dec 2001, Pearu Peterson wrote:
I have been working on the python interface to GiNaC. It is quite usable already and I have tested it in many problems. However, it would be great if some python specific changes that I had to do in GiNaC, could be added to GiNaC. These changes include mostly printing expressions. Earlier I used hooks from GiNaC archive features to get desired output for python, but it was _very_ slow compared to the native GiNaC print hooks.
So, please find a patch attached that adds two new print_context classes, print_python and print_python_repr, with the corresponding additions to print methods of the basic classes. The patch includes also the following change in the idx::print method for print_latex context: `a.b' becomes `a_{b}' if b is covariant, `a^{b}', otherwise (you can ignore it if you don't like it).
This patch is against GiNaC-1.0.1. I can make it also against the latest GiNaC in CVS. Let me know if needed.
I am about to check in your patch. Just one curious question: why the unsigned variable in
unsigned end = nops(); if (end) op(0).print(c); for (unsigned i=1; i<end; ++i) { c.s << ','; op(i).print(c); }
in classes mul and add? Did
op(0).print(c); for (unsigned i=1; i<nops(); ++i) { c.s << ','; op(i).print(c); }
not work? In this case you would have gotten an unevaluated expairseq, which'ld be strange... Also, I am removing the implementation of relational::is_equal_same_type you sent us for 1.0.1 because having relational::compare_same_type is enough by virtue of basic::compare_same_type. Well, theoretically. In practice, removing it brought me rather close to the gates of Heisenbug-madness. See the new lines in inifcns_trans.cpp for a scary moment. May GCC-2.95 soon fade into oblivion! :-( Regards -richy. -- Richard B. Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>
On Wed, 19 Dec 2001, Richard B. Kreckel wrote:
I am about to check in your patch. Just one curious question: why the unsigned variable in
unsigned end = nops(); if (end) op(0).print(c); for (unsigned i=1; i<end; ++i) { c.s << ','; op(i).print(c); }
in classes mul and add? Did
op(0).print(c); for (unsigned i=1; i<nops(); ++i) { c.s << ','; op(i).print(c); }
not work? In this case you would have gotten an unevaluated expairseq, which'ld be strange...
Indeed, it works. Silly me ..
Also, I am removing the implementation of relational::is_equal_same_type you sent us for 1.0.1 because having relational::compare_same_type is enough by virtue of basic::compare_same_type.
I've checked out 1.0.2. All pyGiNaC tests pass fine. Thanks, Pearu
participants (2)
-
Pearu Peterson
-
Richard B. Kreckel