From stefanw at thep.physik.uni-mainz.de Wed May 9 14:35:21 2007 From: stefanw at thep.physik.uni-mainz.de (Stefan Weinzierl) Date: Wed, 9 May 2007 14:35:21 +0200 (CEST) Subject: [GiNaC-devel] Problem with power series Message-ID: Gentlemen, I came across a small problem, when calculating series expansions. The following code hangs, when attempting to compute the expansion: #include #include using namespace std; using namespace GiNaC; int main() { symbol x("x"); ex e1 = pow(2,x)*( 1/x*(-(1+x)/(1-x)) + (1+x)/x/(1-x)); cout << e1 << endl; cout << e1.expand() << endl; cout << e1.series(x,1) << endl; } I tried it with GiNaC 1.3.7 as well as 1.3.1 and 1.3.0. e1 is actually a complicated zero, and the correct answer should we O(x). Best wishes, Stefan From Chris.Dams at mi.infn.it Wed May 9 16:27:52 2007 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Wed, 9 May 2007 16:27:52 +0200 (CEST) Subject: [GiNaC-devel] Problem with power series In-Reply-To: Message-ID: Dear Stefan, > I came across a small problem, when calculating series expansions. > The following code hangs, when attempting to compute the expansion: Yes, this is a known problem. It is not that easy to solve in general, unfortunately. If I finish my patch for introducing inner products into GiNaC, I think I will have a look at this. Best wishes, Chris From stefanw at thep.physik.uni-mainz.de Thu May 10 09:12:01 2007 From: stefanw at thep.physik.uni-mainz.de (Stefan Weinzierl) Date: Thu, 10 May 2007 09:12:01 +0200 (CEST) Subject: [GiNaC-devel] Problem with power series In-Reply-To: Message-ID: Dear Chris, attached is a patch (against GiNaC 1.3.7) which should fix the problem. A few explanations: If one does a series expansion up to n of a product A*B we have to know the ldegree of B in order to determine how far we have to expand A (and vice versa). Currently the implementation finds for each factor the ldegree first, by expanding it to order 1,2,3,4,etc until a non-vanishing ldegree is found. If a factor is a complicated zero, a non-vanishing ldegree is never found and the algorithms loops for eternity. In addition, this is quite inefficient, if a factor has a large ldegree: Then this factor is expanded up to its ldegree, although we only asked for an expansion up to n. The patch splits the computation of the ldegrees into two stages: In the first stage all negative ldegrees are computed. From remco.bloemen at gmail.com Wed May 16 14:31:00 2007 From: remco.bloemen at gmail.com (Remco Bloemen) Date: Wed, 16 May 2007 14:31:00 +0200 Subject: [GiNaC-devel] Symbolic Integration Message-ID: <200705161431.00599.R.Bloemen@student.utwente.nl> Dear developers, I have been using the Ginac library for some of my hobby programs now and I believe a generic C++ CAS would be very valuable. I have grown interest in symbolic integration and tried implementing polynomial factorization, it seems quite hard to do efficiently, but doable. I have even bought the book mentioned in the todo list (the second edition). Altough I have just began to read it the book mentions that some recent algorithms for trancedental integration do not require polynomial factorization. So I would like to try and implement one of these algo's. My question is, what are your thoughts on how to implement integration in a nice fashion? I tought about implementing some kind of antiderivative operator wich can be used in expressions and gives the indefinite integral. The reason I preffer operators to member function is that it allows unsolvable integrals to remain in the equation and still be numerically evaluable. In this fashion I would like to create a differential operator so ODE's and PDE's can be expressed in Ginac and numerically solved. The hobby program I am trying to make should become a generic numerical integrator for arbitrary PDE's by dynamicaly generating code. I already have a class that converts an expression to its Chebyshev-Pade approximation, compiles it to double arithmetic and dynamicly links it in. So gentleman, what are your thoughts? Sincerely, R. Bloemen From Chris.Dams at mi.infn.it Wed May 16 17:29:41 2007 From: Chris.Dams at mi.infn.it (Chris.Dams at mi.infn.it) Date: Wed, 16 May 2007 17:29:41 +0200 (CEST) Subject: [GiNaC-devel] Problem with power series In-Reply-To: References:

Message-ID: <24075.193.205.79.62.1179329381.squirrel@webmail.mi.infn.it> Dear Stefan, > attached is a patch (against GiNaC 1.3.7) which should fix the problem. I committed this patch. Thanks for it. I also added the failed check that you posted to the exams. BTW: if you submit any more patches, could you please make a diff from the old file to the new instead of the other way around? Best wishes, Chris From Chris.Dams at mi.infn.it Wed May 16 17:50:59 2007 From: Chris.Dams at mi.infn.it (Chris.Dams at mi.infn.it) Date: Wed, 16 May 2007 17:50:59 +0200 (CEST) Subject: [GiNaC-devel] Symbolic Integration In-Reply-To: <200705161431.00599.R.Bloemen@student.utwente.nl> References: <200705161431.00599.R.Bloemen@student.utwente.nl> Message-ID: <3710.193.205.79.62.1179330659.squirrel@webmail.mi.infn.it> Beste Remco, > My question is, what are your thoughts on how to implement integration in > a > nice fashion? I tought about implementing some kind of antiderivative > operator wich can be used in expressions and gives the indefinite > integral. > The reason I preffer operators to member function is that it allows > unsolvable integrals to remain in the equation and still be numerically > evaluable. In this fashion I would like to create a differential operator > so > ODE's and PDE's can be expressed in Ginac and numerically solved. There is already a class "integral" in GiNaC, as you may know. This class contains a left and a right boundary, so it is not immediately suitable for representing an indefinite integral, but I think it could be made suitable. Instead of holding a left and a right boundary, it could hold a more general "integration_region" object that should be in a certain state in the case of an indefinite integral or in another state representing an interval. The advantage is that this way it is not necessary to introduce a new class for a different kind of integral. Veel succes! Chris From kisilv at maths.leeds.ac.uk Fri May 25 14:50:17 2007 From: kisilv at maths.leeds.ac.uk (Vladimir Kisil) Date: Fri, 25 May 2007 13:50:17 +0100 Subject: [GiNaC-devel] Re: Clifford base names WAS: Re: [GiNaC-list] How can I get a GiNaC::ex's name In-Reply-To: <1180082924.19192.113.camel@s161m123.unavarra.es> References: <5400aeb80705240346m4568b6e2x198b53e87a563819@mail.gmail.com> <1180032618.6631.3.camel@localhost.localdomain> <1180082924.19192.113.camel@s161m123.unavarra.es> Message-ID: <3032.1180097417@localhost> Dear Javier, >>>>> "JRG" == Javier Ros Ganuza writes: JRG> It woul be interesting to have this posibility, tough elements JRG> of diferent basis are right now plotted in the same way. Indeed it may be worth to see a difference in the output for Clifford units with different representation labels. I include a patch which give this in the way which is shown by such an example: #include using namespace std; using namespace GiNaC; int main() { try { varidx mu(symbol("nu", "\\nu"), 3); ex basis1 = clifford_unit(mu, diag_matrix(lst(1, 1, 1)),0), basis2 = clifford_unit(mu, diag_matrix(lst(1, 1, 1)),1); ex e00 = basis1.subs(mu == 0), e10 = basis2.subs(mu == 0); cout << e00 << endl; // <-- e~0 cout << e10 << endl; // <-- e[1]~0 } catch (exception &p) { cerr << "Got problem: " << p.what() << endl; } } Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv at maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/ -------------- next part -------------- A non-text attachment was scrubbed... Name: ginac.diff Type: text/x-c++ Size: 1011 bytes Desc: Patch for clifford.cpp URL: