- GiNaC-list - ginac.de

Symbolic computation and derivatives
by Antoine Begault 16 May '07

16 May '07

Hello, I am currently trying the functionalities of GiNaC in order to translate some Maple code to C++ code, for a Matrix-using application. But I'm facing some difficulties for which some help could be very useful. First, I need to represent a symbolic vector and then functions of this vector. So far, I've been using 'n' distincts symbols for a vector of size 'n', which is certainly not the best way, especially for what I need to do afterwards (c.f the example below). Then, I need to compute the derivative of a function with respect to the previous vector, i.e. a gradient or a Jacobian matrix. With the "n distinct symbols" solution, I would do that by derivating n times, but it would be much more efficient if the whole gradient computation could be done in only one step: do you see any better way to do so within GiNaC? Finally, it happens that this vector is itself a function of time and I need sometimes to compute derivatives of functions of this vector with respect to time (in a more efficient way than just computing the aforementioned gradient or Jacobian and remultiplyling it by the time-derivative of the vector). I need therefore to express that a symbol (the members of the vector) is in fact a function of another symbol, with respect to which I can compute derivatives. How we do this in Maple is substitute symbols q[i] by functions q[i](t), differentiate with respect to t, then substitute back q[i](t) with q [i] and diff(q[i](t),t) with qdot[i] with the following code: > R=matrix(3,3);//+ initialization > map(x->subs({seq(q[i](t)=q[i], i=1..NDDL), > seq(diff(q[i](t), t)=qdot[i], i=1..NDDL)}, > diff(subs({seq(q[i]=q[i](t), i=1..NDDL)}, x), t)), P)): Doing something similar with GiNaC requires that we deal with user defined functions, but the "function" objects don't look like they are really made on this purpose: am I understanding correctly? We would define 'n' functions q[i](t) with derivatives defined as 'n' other functions qdot [i](t), something like that, but isn't there any simpler and more effective way? Many thanks for your time and help, A. Begault. -- View this message in context: http://www.nabble.com/Symbolic-computation-and-derivatives-tf3726576.html#a… Sent from the Ginac - General mailing list archive at Nabble.com.

2 1

Re: [GiNaC-devel] Problem with power series
by Chris.Dams＠mi.infn.it 09 May '07

09 May '07

Dear Stefan, > can you briefly tell me what the problem is ? Look at the file pseries.cpp. See: http://www.ginac.de/viewcvs/GiNaC/ginac/pseries.cpp?rev=1.93&view=markup . The method mul::pseries contains the code fragment. int real_ldegree = 0; try { real_ldegree = buf.expand().ldegree(sym-r.rhs()); } catch (std::runtime_error) {} if (real_ldegree == 0) { int orderloop = 0; do { orderloop++; real_ldegree = buf.series(r, orderloop, options).ldegree(sym); } while (real_ldegree == orderloop); } The do ... while loop looks for the lowest degree for which the series is nonzero. This is done for very factor in a product. Hence, if there is never going to occur a term in the series that is nonzero, there is a problem. I would like to see a solution where there is besides a series method also a method that returns the leading term, that may also return a result that says that no leading term was found up to a certain order. Best wishes, Chris

1 0

Are Clifford units of different bases equal?
by Javier Ros Ganuza 09 May '07

09 May '07

Hello all, I think that I can explain myself better with this simplistic example (THE OUTPUTS OF COUTS ARE INLINED): //gcc -o main1 main1.cc -lginac -lcln #include <ginac/ginac.h> using namespace std; using namespace GiNaC; int main(){ realsymbol a1("a1"), b1("b1"), c1("c1"); varidx nu(symbol("nu", "\\nu"), 3), mu(symbol("mu", "\\mu"), 3); ex basis1 = clifford_unit(mu, diag_matrix(lst(1, 1, 1)),0), basis2 = clifford_unit(nu, diag_matrix(lst(1, 1, 1)),1); ex vector1 = lst_to_clifford(lst(a1,b1,c1), mu, basis1), vector2 = lst_to_clifford(lst(a1,b1,c1), nu, basis2); ex result=2*vector1+vector2; cout << result << endl; //GIVES: e~nu*[[a1],[b1],[c1]].nu+2*[[a1],[b1],[c1]].mu*e~mu cout << result.expand(expand_options::expand_indexed).simplify_indexed() << endl; //GIVES: 3*e~nu*[[a1],[b1],[c1]].nu cout << expand_dummy_sum(result) << endl; //GIVES: 3*a1*e~0+3*c1*e~2+3*b1*e~1 cout << canonicalize_clifford(expand_dummy_sum(result)) << endl; //GIVES: 3*a1*e~0+3*c1*e~2+3*b1*e~1 } So I understand that basis1 and basis2 are the units of two different bases, the last parameter (0 or 1) in the call of clifford_unit(...) does not affect the output (about this parameter the tutorial says: "optional parameter rl allows to distinguish different Clifford algebras (wich will commute each other))". I recognize that I don't understand the meaning of "wich will commute each other" ). I understand then that vector1 and vector2 are vectors with the same components but with different bases. But Outputs reveal: Output 1: Clifford_unit names are the same for both bases Output 2: Clifford_units are the same for both bases Output 3: Clifford_units are the same for both bases Output 4: Clifford_units are the same for both bases Is this intended behaviour? Can it be changed so that Outputs can be something like this: e_basis2~nu*[[a1],[b1],[c1]].nu+2*[[a1],[b1],[c1]].mu*e_basis1~mu e_basis2~nu*[[a1],[b1],[c1]].nu+2*[[a1],[b1],[c1]].mu*e_basis1~mu 2*a1*e_basis2~0+2*c1*e_basis2~2+2*b1*e_basis2~1+a1*e_basis1~0 +c1*e_basis1~2+b1*e_basis1~1 2*a1*e_basis2~0+2*c1*e_basis2~2+2*b1*e_basis2~1+a1*e_basis1~0 +c1*e_basis1~2+b1*e_basis1~1 ??? Another question: In expresion vector1*vector2, Does * stands for the Inner product? How can I write a expression involving the Outer product? As Vladimir may remember, this is a rework of a example that appeared in this list a couple of years ago. I have implemented a multibody dynamics kernel based in GiNaC around clases derived form GiNaC's matrix, but I want to investigate this path also. Javier PD: I'm ussing ginac-1.3.4-1.fc4 for if it is relevant.

2 5

Re: [GiNaC-list] question about quantum operator algebra
by Chris Dams 09 May '07

09 May '07

Dear Can-Hua, > > { ... constructing the result of rewriting is done here ... > > Sorry, but I have no idea what goes here. Could you show me somewhere > to find examples? Thank you. Your function could look like the following ex rewrite_operators(const ex &x) { if (is_a<ncmul>(x)) { if (x.has(one)) { exvector v; v.reserve(x.nops()); for (int i=0; i<x.nops(); ++i) if (x.op(i) != one) v.push_back(x.op(i)); if (v.empty()) v.push_back(one); return rewrite_operators(ncmul(v)); } for (int i=0; i<x.nops()-1; ++i) if (x.op(i) == adag && x.op(i+1) == a) { exvector v; v.reserve(x.nops()); for (int j=0; j<i; ++j) v.push_back(x.op(j)); v.push_back(one+a*adag); for (int j=i+2; j<x.nops(); ++j) v.push_back(x.op(j)); return rewrite_operators(expand(ncmul(v))); } return x; } else return expand(x.map(rewrite_operators)); } Note that it is necesary to also declare an element "one" for your algebra because one cannot add numbers and noncommutative objects. Best wishes, Chris

1 0

Re: [GiNaC-list] question about quantum operator algebra
by Canhua 08 May '07

08 May '07

> Date: Sat, 5 May 2007 11:13:49 +0200 (CEST) > From: Chris.Dams(a)mi.infn.it > Subject: Re: [GiNaC-list] question about quantum operator algebra > To: "GiNaC discussion list" <ginac-list(a)ginac.de> > You can declare those operators as noncommutative symbols. I assume that > you are using version 1.3.x. Then it goes as e.g., > > const unsigned my_tinfo = 2; > symbol a("a", return_types::noncommutative, my_tinfo); > symbol adag("adag", return_types::noncommutative, my_tinfo); > H = epsilon*adag*a; > ex commu = a*H - H*a > commu = rewrite_operators(commu); > > The global constant my_tinfo is arbitrary, but for safety it should not be > one that is already in use (see > http://www.ginac.de/viewcvs/GiNaC/ginac/tinfos.h?hideattic=0&rev=1.27.2.3&v…) > You would have to define the function rewrite_operators yourself. It could > be something like > > ex rewrite_operators(const ex &x) > { if (is_a<ncmul>(x)) > { ... constructing the result of rewriting is done here ... Sorry, but I have no idea what goes here. Could you show me somewhere to find examples? Thank you. > return result; > } > else > return x.map(rewrite_operators); > } Best regards, Can-Hua Chen

1 0

Lie algebra realisation with GiNaC
by Vladimir Kisil 07 May '07

07 May '07

Dear All, Here is a revised example of Lie algebras realisation in GiNaC as derived class from clifford. It is essentially the same as before: http://www.ginac.de/pipermail/ginac-devel/2005-July/000793.html but now works with 1.4 branch (new TINFO system). Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/

1 0

question about quantum operator algebra
by Canhua 06 May '07

06 May '07

hi, I am searching for a software or library that can handle operator algebra in quantum mechanics. For example, I would like to caculate the commutator [a,H], where the Hamiltonian "H"=\epsilon a^{\dag}a, and "a" is annihilation operator for, say, an osilator. I tried GiNaC, and read much documentation, and get little clue. I wonder if there is a direct implementation of these kind of operator algebra in GiNaC. Thank you in advance.

4 3

Fwd: cygwin and GiNaC
by lolson＠ualberta.ca 04 May '07

04 May '07

Hello, hopefully someone can help me out with this. I am trying to get GiNaC working with cygwin. I installed the cln and ginac libraries with no problems at all. I can run ginsh no problem. However, when I go to compile a sample program in the tutorial. I get a TON of errors, most saying undefined reference. I'll copy part of the error log so you can see: /usr/local/lib/libginac.a(inifcns.o): In function `_ZN5GiNaC6fsolveERKNS_2exERKNS_6symbolERKNS_7numericES8_': /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/lib/libginac.a(inifcns.o):/usr/local/include/cln/object.h:216: more undefined references to `cln::cl_free_heap_object(cln::cl_heap*)' follow /usr/local/lib/libginac.a(numeric.o): In function `_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ES3_RKS6_': /usr/local/include/cln/object.h:(.text+0x7): undefined reference to `cln::cl_R_ring' /usr/local/lib/libginac.a(numeric.o): In function `_ZNK5GiNaC7numeric11is_rationalEv': /usr/local/include/cln/ring.h:417: undefined reference to `cln::cl_RA_ring' /usr/local/lib/libginac.a(numeric.o): In function `_ZNK5GiNaC7numeric10is_integerEv': /usr/local/include/cln/ring.h:417: undefined reference to `cln::cl_I_ring' /usr/local/lib/libginac.a(numeric.o): In function `_ZN5GiNaC7numericC2Ev': /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/lib/libginac.a(numeric.o): In function `_ZN5GiNaC7numericC1Ev': /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/lib/libginac.a(numeric.o):/usr/local/include/cln/object.h:216: more undefined references to `cln::cl_free_heap_object(cln::cl_heap*)' follow /usr/local/lib/libginac.a(numeric.o): In function `_ZN5GiNaC7numericC2Ei': /usr/local/include/cln/integer_class.h:52: undefined reference to `cln::cl_I_constructor_from_L(long)' /usr/local/lib/libginac.a(numeric.o): In function `_ZN5GiNaC7numericC2Ei': /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/lib/libginac.a(numeric.o): In function `_ZN5GiNaC7numericC1Ei': /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/lib/libginac.a(numeric.o): In function `_ZN5GiNaC7numericC1Ei': /usr/local/include/cln/integer_class.h:52: undefined reference to `cln::cl_I_constructor_from_L(long)' /usr/local/lib/libginac.a(numeric.o): In function `_ZN5GiNaC7numericC1Ei': /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/lib/libginac.a(numeric.o): In function `_ZN5GiNaC7numericC2Ej': /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' and thats just the start of it. Does anyone know what is causing this. Please help! Thanks, Lane.

2 1

Some static functions
by Martin Sandve Alnæs 14 Apr '07

14 Apr '07

collect_symbols and get_symbol_stats are mentioned in the manual, but are defined as static functions in normal.cpp with no mention in normal.h. Does this mean they're meant to be internal and not part of the "official" API? I'd like to use them... -- --- Martin Sandve Alnæs PhD student, Cardiac Computations Simula Research Laboratory, Norway

3 3

Re: [GiNaC-list] Problem using a user-defined class on Mac OS X.
by Chris.Dams＠mi.infn.it 09 Apr '07

09 Apr '07

Dear David > This alone doesn't exhibit the issue in the original example. > What you've written above is just a plain partial specialization, no > violation at all. Now, suppose that the last definition above > (foo<T*>::data) was replaced in a *different* translation unit with: > > template <> void* foo<void*>::data = &something_else; > > which is similar to the original code in this thread. The instantiation > of foo<void*>::data can now be different-valued. (Is this analogous to > the GiNaC source or proposed patch in question?) No, there is only one instantiation in the GiNaC source. Both in the unmodified one and the one that I modified to work on Mac OS X. So it cannot have different values. The point is that in the original GiNaC code there would be two instances of, say, foo<void*>::data inside the executable. One comming from the shared library and the other one coming from the executable itself. Library code would modify the first one and code from the executable would modify the other one. To reproduce it in toy code, I think you would have to create a dynamic library on the Mac, but I havn't tried yet. I guess, it could have something to do with the so-called two-level namespaces that the man page of the linker talk about. I could test that. Best wishes, Chris

2 3