- GiNaC-list - ginac.de

Extracting monomials from a polynomial
by Anish Muttreja 11 Apr '04

11 Apr '04

Hi I am using ginac in a symbolic regression program. It generates different polynomials using genetic programming, mulitplies each monomial by a weight and then fits the resulting expression using regression. I need to extract each monomial from the polynomial. Until now , I have been getting by only dealing with the case where the top level class is "add", and the program worked well enough for me to publish a paper on the use of symbolic regression in software modelling. Yes , I wanted to let the authors know, they have another citation :-). But this restricts the program. Is there a better way to do this ? Will ex::expand () convert the expression to a polynomial I should mention that the ginac expression itself is generated from a genetic evolved tree, so that I can generate all the monomials while doing this conversion, but that will leave me with the task of collecting like terms, something I would rather have done for me :-). Thanks Anish -- Anish Muttreja ~ Graduate Student Electrical Engineering ~ Princeton University ======================================================== As an adolescent I aspired to lasting fame, I craved factual certainty, and I thirsted for a meaningful vision of human life - so I became a scientist. This is like becoming an archbishop so you can meet girls. -Matt Cartmill, anthropology professor and author (1943- )

2 2

Vectors
by Olivier Parisy 09 Apr '04

09 Apr '04

Hi, I'd be interested in representing cartesian vectors in GiNaC. I suppose I could represent one using a matrix, but having a specific node for it and, as an example, for cross product or vectors sum would allow for higher-level expressions representation. I didn't see any hint for this in the current GiNaC distribution or in its todo list, but perhaps anyone already did it ? Any advice ? Regards, Olivier Parisy.

1 0

series expansion once again...
by varg＠thsun1.jinr.ru 05 Apr '04

05 Apr '04

Hello! > Series expansion now works predictably. All terms with the exponent > of the expansion variable smaller than the given order are > calculated exactly. If the series is not terminating, the Order > function is (at least) of the given order. ( GiNaC 1.1.7 changelog ) That sounds nice, but let's consider a simple program. #include <iostream> #include <stdexcept> using namespace std; #include <ginac/ginac.h> using namespace GiNaC; int main(int argc, char** argv) { try { symbol eps("epsilon"); ex part1 = tgamma(2-eps)*pow(eps, -1)*pow(tgamma(3-eps), -1); ex part2 = tgamma(2-eps)*pow(eps, 2)*pow(tgamma(3-eps), -1); ex test = part1 + part2; cout << test << " = " << test.series(eps, 1) << endl; cout << part1 << " = " << part1.series(eps, 1) << endl; cout << part2 << " = " << part2.series(eps, 1) << endl; return 0; } catch ( exception & ee) { cerr << ee.what() << endl; return 1; } } My naive expectations are: 1) first and second lines should be the same 2) third line should be Order(epsilon) But the output is: tgamma(2-epsilon)*tgamma(3-epsilon)^(-1)*epsilon^2+tgamma(2-epsilon)*tgamma(3-epsilon)^(-1)*epsilon^(-1) = Order(epsilon^(-1)) tgamma(2-epsilon)*tgamma(3-epsilon)^(-1)*epsilon^(-1) = 1/2*epsilon^(-1)+1/4+Order(epsilon) tgamma(2-epsilon)*tgamma(3-epsilon)^(-1)*epsilon^2 = Order(epsilon^(-1)) Is this a bug or a feature? Thanks, Alexei. P.S. $ ginac-config --version 1.1.7 $ g++ --version | head -n 1 g++ (GCC) 3.3.3 (Debian 20040401)

3 2

How to calculate the area of a circle?
by Tom Brinkman 29 Mar '04

29 Mar '04

How do i solve for the area of a circle? Example: symbol r("r"); ex e = pow(r,2) * Pi == 30; ex solve = lsolve(e,r); //This example does not work. An error message indicating that this is not a linear equation is returned. How do I solve for "r" in this case. //Could you also show an example of how to solve for a simple polynomial, such as: ex = pow(a,2) + a = 3 How do i solve for "a". regards, Tom Brikman __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html

2 1

troubles with ginac 1.2 on debian unstable
by Andrius Kurtinaitis 25 Mar '04

25 Mar '04

Hello, i was so happy about 1.2 release, that I downloaded the new 1.2 version of ginac, compiled and installed on my debian unstable machine, using usual configure, make, su, make install. I also have another ginac version 1.1.6-1 installed. When I build a simple proggy using ginac, I use new (1.2) ginac lib and the old cln: g++ -o charpoly charpoly.cpp /usr/local/lib/libginac.a -lcln The resulting program crashes with the segmentation fault. Even if it does nothing. Including <ginac/ginac.h> and compiling the empty program is enough to produce the segfault. The current installation contains the cln version 1.1.6-1. Any hints? I thought, it is because of version incompatibility between the cln library and the new ginac. Then i tried to download the newest cln, which, according to its site should be 1.1.7. But the download site ftp://ftpthep.physik.uni-mainz.de/pub/gnu/ does not contain this version... Or is it because of different compiler versions used to compile cln and my own ginac 1.2? Any ideas? Andrius Kurtinaitis

4 8

GiNaC 1.2.0 now available
by Christian Bauer 19 Mar '04

19 Mar '04

Hello! In an unforeseen turn of events, the GiNaC Group (who, by the way, don't endorse the use of recreational drugs, except for C++ templates and Pokemon movies) proudly presents GiNaC 1.2.0 "We don't have the funds for champagne but we're going to release anyway". (And we also finally leave CLN in the dust in terms of version numbers. Hah, in your face, Richy! :-) Compared to the last few 1.1.x releases, this one has a rather impressive list of changes, with the focus on improving GiNaC's extensibility: - Added a structure<T> template class for the easy creation of user-defined algebraic classes. - Added support for (acyclic) visitors, to allow cleaner implementations of algebraic algorithms. - Added a const_iterator class that can be used instead of op()/nops(). - Completely revamped the implementation of expression output. It is now possible to add new output formats, to change the behavior of predefined formats at run-time, and to have different output styles for algebraic functions. - Symbols can be made non-commutative. - Added a method ex::conjugate() and a function conjugate() for complex conjugation. Symbols can be declared as real or complex-valued. - Improved the speed of subs(), normal(), to_rational() and to_polynomial() by the use of maps instead of lists. The old forms subs(const lst & ls, const lst & lr, unsigned options) to_rational/to_polynomial(lst & repl) are still available for compatibility, but using the new forms subs(const exmap & m, unsigned options) to_rational/to_polynomial(exmap & repl) is more efficient, especially when the number of replacements is large. - quo(), rem(), prem(), sprem(), decomp_rational(), unit(), content(), primpart() and matrix::charpoly() now take a "const ex &" instead of a "const symbol &". - Redundant expressions (two ex pointing to different objects are found to be equal in compare()) are now actively deleted/fused to conserve memory and speed up subsequent comparisons. This behavior can be suppressed on a per-object level with status_flags::not_shareable. Lists and matrices are not shareable by default. - Lots of internal streamlining and optimizations. - Caveats for class implementors: - basic::copy() and basic::destroy() are gone; classes derived from basic can use the defaults for the assignment operator and copy constructor. [Roberto: this also means that annoying compiler warning is finally gone... :-] - basic::subs(), basic::normal(), basic::to_rational() and basic::to_polynomial() take 'exmap' objects instead of lists. - basic::subs() now descends into subexpressions (if accessible via nops()/op()/let_op()). If you have a custom implementation of subs() that calls basic::subs() after substituting subexpressions, this needs to be changed to a call to subs_one_level(). - lst::thislst() and exprseq::thisexprseq() renamed to thiscontainer(). - thiscontainer() and associated constructors now take a std::auto_ptr. - Overloading basic::print() is now deprecated. You should use print_func<>() class options instead. Most of the new features are explained in more detail in the tutorial. GiNaC 1.2.0 is not binary compatible to 1.1.x, so you have to recompile your stuff. It shouldn't be necessary to make any modifications to your sources when switching to 1.2, except when you implemented your own GiNaC classes (see above). As before, all 1.2.x releases will be (upwards) binary compatible to each other. There is a new CVS branch "ginac_1-2" for the 1.2.x series, and the CVS head branch will eventually become GiNaC 1.3 (or GiNaC 2.0, or GiNaC Advanced Datacenter Edition, or whatever). What's left to say? Ah, yes, download GiNaC 1.2.0 from ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC Happy computing, Christian -- / Physics is an algorithm \/ http://www.uni-mainz.de/~bauec002/

1 0

GiNaC 1.1.7 now available
by Christian Bauer 11 Mar '04

11 Mar '04

Hello! We're proud to present GiNaC release 1.1.7 "Legacy of Taylor" in which we: - Fixed a bug in canonicalize_clifford(). - Series expansion now works predictably. All terms with the exponent of the expansion variable smaller than the given order are calculated exactly. If the series is not terminating, the Order function is (at least) of the given order. Predictably, this release can be downloaded from ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC/ Never stop coding, Christian -- / Physics is an algorithm \/ http://www.uni-mainz.de/~bauec002/

1 0

differential operators
by Kai Ludwig 29 Feb '04

29 Feb '04

Hi All, I'm new to GiNac. Is there a way to execute symbolic differentiation of expressions that includes differential operators ? e.g. suppose an expression ex F = u * dx*u When differentiate that expression F.diff(u) it should result in the expression dx*u - u*dx Regards Kai -- http://echempp.sourceforge.net Kai Ludwig Universität Tübingen Institut für Organische Chemie Auf der Morgenstelle 18 D-72076 Tübingen Tel.: 07071/29-73049 Mail: kai.ludwig(a)uni-tuebingen.de

4 10

Problems with order parameter of 'series' method
by Holger Eberle 19 Feb '04

19 Feb '04

Hello, when applying the 'series' method to an expression which only constists of adds, muls and pows, the final order of the expansion does not seem to depend pretictably on the parameter 'order' of 'series', e.g. symbol eps("eps"); ex expr = (pow(eps, 8)*pow(pow(eps,3)+ pow(eps + pow(eps,3), 2),-2)) .series(eps==0, 6); cout << "expr: " << expr << endl; produces "expr: Order(eps^2)" and not as expected (by me) "expr: 1*eps^4+(-2)*eps^5+Order(eps^6)" The first order parameter the expansion works correctly with again is 9, then I get an expansion up to Order(eps^13)... Does anyone know how to remedy that or at least how to handle series of this quite general type of expressions predictably? Thanks! Holger Eberle

3 4

matrix in \frac{}{}
by Bodo Steiner 17 Feb '04

17 Feb '04

Hi, I'm trying to get this running, but it won't ... how can I have a matrix in the following formula: \begin{equation} \alpha^{\star}=\frac{\mbox{\boldmath$z$}^{T}\mbox{\boldmath$\Lambda$} \mbox{\boldmath$\Sigma$}}{\mbox{\boldmath$z$}^{T}\mbox{\boldmath$\Lambda$} \begin{bmatrix}-\mbox{\boldmath$K$}_{1}^{-1}&0\\ 0&\mbox{\boldmath$K$}_{2}^{-1} \end{bmatrix}\mbox{\boldmath$\Lambda$}^{T}\mbox{\boldmath$z$} +r\mbox{\boldmath$z$}^{T}\mbox{\boldmath$\Lambda$} \mbox{\boldmath$\Sigma$}\mbox{\boldmath$\Lambda$}^{T}{\mbox{\boldmath$z$}} \end{equation} thanks! -bodo.

2 1