August 2001 - GiNaC-devel

dead link at http://www.ginac.de/
by keith.briggs＠bt.com 24 Aug '01

24 Aug '01

Dear GiNaC people, Your link CLN Class Library for Numbers <http://clisp.cons.org/~haible/packages-cln.html> at http://www.ginac.de/ seems to be dead. Best wishes, Keith Dr. Keith M. Briggs Senior Mathematician, Complexity Research, BTexact Technologies email: Keith.Briggs(a)bt.com phone: +44(0)1473 work: 641 911 home: 625 972 fax: 647 410 web: www.btexact.com/people/briggsk2/ mail: Keith Briggs, Antares 2pp5, Adastral Park, Martlesham, Suffolk IP5 3RE, UK

1 0

Bug in print2 of Tutorial
by Pearu Peterson 21 Aug '01

21 Aug '01

Hi, Shouldn't the lines n.find_bool(name, x); n.find_unsigned(name, x); n.find_string(name, x); in static void my_print2(const archive_node & n); of the Tutorial be replaced with the following ones: n.find_bool(name, x, j); n.find_unsigned(name, x, j); n.find_string(name, x, j); ? I noticed that when extracting info from fderivative instance. I was expecting 'D[0,1](f)(x,y)' but I was getting 'D[0,0](f)(x,y)' from 'f(x,y).diff(x).diff(y)'. The change above fixed this. As I understand, then all items in property p[i] should be of the same type. Is this always true? Regards, Pearu

2 1

PROPOSAL: Dynamic creation of functions
by Pearu Peterson 20 Aug '01

20 Aug '01

Dear GiNaC developers, In "What doesn't belong into GiNaC" section of GiNaC tutorial you encourage using GiNaC as a bottom of a complete CAS. I have used GiNaC in connection with Python language and found that such a combination can be very close to a perfect environment that has powerful programming capabilities with efficient symbolic algebra support. However, GiNaC lacks one important feature, that is, creating new functions in runtime. It is clear that within C++ environment it is not desired (if not impossible) as users can define their functions at the compilation stage. In scripting languages, however, new functions can be defined only in runtime. Therefore, I have been looking ways how to create new functions to GiNaC without forcing re-compilations of C++ codes. One can find different approaches for that but they all require some modifications to GiNaC sources. So, I am writing to you with a hope that these modifications could be done in GiNaC repository, rather than by me or anybody else with a similar projects, each time as a new version of GiNaC is released. After trying out many approaches, I have reached to the following conclusion: It is impossible to define dynamic functions in GiNaC because the variables function_options::eval_f,evalf_f,series_f,derivative_f must point to static functions where is impossible to determine what function called it (that is, with what serial number). Now, let me describe a solution to this problem: 1) (Interface authors) define special functions dynfunc_eval_f,etc as follows (I'll use Python C/API for illustrations): ex dynfunc_eval_f(const exvector & seq) { unsigned serial = function::current_serial; //see below (3) PyObject *func = dynfunc_eval_cache[serial]; //see below (2) /* Implement call: result = func(seq), specific to different languages */ return result; } 2) Dynamic functions are created by calling the following (a minimal implementation): void build_function(const string & name, unsigned nparams, PyObject* py_eval_func, //pointers to Python functions PyObject* py_evalf_func, ...) { function_options opts; opts = set_name(name).eval_func(dynfunc_eval_f); // NOTE: all dynamically created functions have the same eval_f. // There, using cache and serial, appropriate Python function is called. // See above (1) opts.test_and_set_params(nparams); unsigned serial = function::register_new(opts); // Store Python function in cache: dynfunc_eval_cache[serial] = py_eval_func; } where std::map<unsigned, PyObject*> dynfunc_eval_cache; is defined in the interface space (similarly are defined hooks for evalf,series,derivative). 3) The following definitions would be new to GiNaC: typedef ex (* GiNaC::eval_funcp_v)(const exvector &); function_options& function_options::eval_func(eval_funcp_v e) { use_vector_args = true; eval_f = eval_funcp(e); return *this; } class function_options { ... protected: bool use_vector_args; /* are to be set false by default */ }; class function { ... public: static unsigned current_serial; }; and in GiNaC::function::eval the following lines are added just before the 'switch (opt.nparams) {..}' statement: if (registered_functions()[serial].use_vector_args) { current_serial = serial; eval_result = ((eval_funcp_v)(registered_functions()[serial].eval_f))(seq); } else Similar hooks are added to functions GiNaC::function::eval,series,pderivative. What do you think? Can I can implement/test these modifications and send you them as a patch? Thanks, Pearu

2 4

Cannot evaluate numerically 2^Pi, for instance.
by Pearu Peterson 20 Aug '01

20 Aug '01

Hi, I have found that when calling evalf() method for a power instance, its exponent is not evaluated. Here follows an example that demonstrates this: include <ginac/ginac.h> using namespace GiNaC; using namespace std; int main(void) { ex e = pow(2, Pi); cout << "e="; e.print(print_context(cout)); cout << endl; cout << "e.evalf()="; e.evalf().print(print_context(cout)); cout << endl; return 0; } The output is: e=2^Pi e.evalf()=(2.0)^Pi And I don't see anything wrong in ex power::evalf(int level) const; Do you? Regards, Pearu

2 1

Re: GiNaC/ginac basic.cpp numeric.cpp operators.cpp power.cpp pseries.cpp symbol.cpp wildcard.cpp
by Pearu Peterson 20 Aug '01

20 Aug '01

> - carried on with felonious plot about making ex::bp private. Sorry that I haven't checked out the details of this evil plot as I am a bit afraid it will broke something in my project (pyginac - Python interface to GiNaC). But here follow my concerns. For this interface I use the following expressions: e.bp->precedence(); e.bp->class_name(); (GiNaC::lst &)(*(e.bp)); (GiNaC::numeric &)(*(e.bp)); (GiNaC::symbol &)(*(e.bp)); etc. where e is an ex instance. Will there be ways to write these expressions after your plot is complete? Pearu

2 1

bug(?): garbage produced by archive_node.get_string
by Pearu Peterson 18 Aug '01

18 Aug '01

Hi, Note that if one uses static void my_print2(const archive_node & n); from the GiNaC Tutorial for expressions that has lenghty string then the result of get_string produces some garbage at the end of string. For example, the following code int main(void) { ex e = pow(200, 500); archive ar(e, "e"); my_print2(ar.get_top_node(0)); cout << endl; return 0; } outputs numeric(number="3273390607896141870013189696827599152216642046043064789483291368096133796404674554883270092325904157150886684127560071009217256545885393053328527589376000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000|õÿ¿_+@xÔõÿ¿") I am using GiNaC 0.9.2, gcc 2.95.2, Linux MD 7.0. Best regards, Pearu

2 8

None
by Richard B. Kreckel 16 Aug '01

16 Aug '01

We are psyched to announce GiNaC 0.9.3. This release is even more fat-, meta-tag-, cholesterol- and bug-free than earlier versions: * Series expansion is now much more consistent for very small order expansion, giving some users unprecedented expressiveness and * lsolve() accepts an algorithmic hint as parameter so one can squeeze out ultimate performance. Get your copy as long as our supply of this groundbreaking product lasts!

1 0

Most elegant way to get from (ex) to (void *)?
by Duraid Madina 14 Aug '01

14 Aug '01

Hi all, What's the most elegant way (okay, fastest way) to translate between expressions and plain-old arrays of bytes? (of course, I am interested in both directions!) Right now I've got a really kludgy system that takes the expression, 'archives' it, sends that archive into an 'strstream' buffer, and then grabs the 'string' backing that strstream, et voila. Any better ideas? ;-) Thanks in advance, Duraid

2 1

ex_to templates
by Pearu Peterson 12 Aug '01

12 Aug '01

Hi! Since ex_to_*() are announced deprecated with the corresponding replacements ex_to<*>() then what about ex_to_nonconst_*()? Will there be ex_to_nonconst<*>()? It just seems logical to have ones. Regards, Pearu

1 0

GiNaC memory leak?
by Marko Riedel 09 Aug '01

09 Aug '01

Greetings. I am sending some code that I wrote in order to solve a differential equation. You run the compiled program with a command-line argument telling it what terms to use. Interesting values are e.g. 10, 14, 16 and 19. (The higher values take some time to compute.) Warning! When you run the program on the higher values, it starts consuming huge amounts of memory. On a SuSE Linux machine the OS eventually kills the process. What is going on here? The program solves a system of equations with a 1000 x 1000 approx. coefficient matrix. What is all the memory being used for? Take, say 32 bytes per entry; the system should then allocate about 32M of memory. In fact it tries to allocate more than 512M of memory! Best regards, Marko Riedel ---------------------------------------------------------------------- #include <stdio.h> #include <fstream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; static symbol u("u"); static symbol z("z"); static symbol l1("l1"); static symbol l2("l2"); static symbol phi("phi"); static void extracteqs(ex eq, lst *l) { int i, j; ex c1, c2; for(i=eq.ldegree(z); i<=eq.degree(z); i++){ c1=eq.coeff(z, i); for(j=eq.ldegree(u); j<=eq.degree(u); j++){ c2=c1.coeff(u, j); if(is_ex_of_type(c2, numeric)){ if(c2!=0){ cerr << "inconsistency: " << i << " " << j << endl; exit(-1); } } else{ (*l).append(c2==0); cerr << (*l).nops() << endl; } } } } int main(int argc, char **argv) { int maxcoeff, i, j; if(argc!=2){ cout << argv[0] << " <maxcoeff>" << endl; exit(-1); } sscanf(argv[1], "%d", &maxcoeff); if(maxcoeff<1){ cout << "argument " << maxcoeff << " out of range" << endl; exit(-2); } ex rt, lf1, lf2; lst vs; rt=0; lf1=0; lf2=0; for(i=0; i<maxcoeff; i++){ for(j=0; j<maxcoeff; j++){ symbol a; rt+=a*pow(z, i)*pow(u, j); vs.append(a); if(i<maxcoeff-6 && j<maxcoeff-6){ symbol b, c; lf1+=b*pow(z, i)*pow(u, j); lf2+=c*pow(z, i)*pow(u, j); vs.append(b); vs.append(c); } } } cerr << rt << endl; cerr << lf1 << endl; cerr << lf2 << endl; cerr << vs << endl; ex s, sf, sf1, sf2; sf=pow(1-u, 11)*pow(1-z, 7)*pow(1-z*u, 7); sf1=pow(1-u, 9)*pow(1-z, 5)*pow(1-z*u, 5); sf2=pow(1-u, 10)*pow(1-z, 2)*pow(1-z*u, 2); s=rt/sf1+ lf1*u*log(1/(1-z))/sf2+ lf2*log(1/(1-z*u))/sf2; ex f, rz, rzv, rzu, rzvu; f=(u-u*u*z*z)/pow(1-z, 2)/pow(1-z*u, 2); rz=1/pow(1-z, 2); rzv=1/pow(1-z, 2); rzu=rz.subs(z==z*u); rzvu=rzv.subs(z==z*u); ex t1, t2, t3, t4, t5, t6, t7, t8, t9; t1=6*u*u*rzu *f; t2=6*u*u*rzvu*f; t3=6*u*u*rzu *phi; t4=6*u*u*rzu *rz; t5=6*u*u*rzvu*rz; t6=6*u*u*rzu *rzv; t7=6* rz *f; t8=6* rzv *f; t9=6* rz *phi; ex rhs1, rhs2; rhs1=(t1+t2+t4+t5+t6+t7+t8).normal(); rhs2=(t3+t9).normal(); ex eq, eq1; eq=(s.diff(z, 2)-rhs1-rhs2.subs(phi==s)) .subs(lst(log(1/(1-z))==l1, log(1/(1-z*u))==l2)) .expand(); eq1=0; for(i=0; i<eq.nops(); i++){ eq1+=(eq.op(i)*sf).normal().expand(); cerr << "expand: " << i << " " << eq.nops() << endl; } ex leq1=eq1.coeff(l1, 1), leq2=eq1.coeff(l2, 1); eq1=eq1.subs(lst(l1==0, l2==0)); lst ceqs; ex s0=(s.subs(z==0)*pow(1-u, 9)).normal(); ex sz0=(s.diff(z).subs(z==0)*pow(1-u, 9)).normal(); ex i0=(u*pow(1-u, 9)).expand(); ex iz0=((4*u+4*u*u)*pow(1-u, 9)).expand(); cerr << "extract initial: 1" << endl; extracteqs(s0-i0, &ceqs); cerr << "extract initial: 2" << endl; extracteqs(sz0-iz0, &ceqs); cerr << "extract: 1" << endl; extracteqs(eq1, &ceqs); cerr << "eqs: " << ceqs.nops() << endl; cerr << "extract: 2" << endl; extracteqs(leq1, &ceqs); cerr << "eqs: " << ceqs.nops() << endl; cerr << "extract: 3" << endl; extracteqs(leq2, &ceqs); cerr << "eqs: " << ceqs.nops() << endl; ex sl; cerr << "solving: " << ceqs.nops() << " " << vs.nops() << " ..." << endl; try{ sl=lsolve(ceqs, vs); } catch(exception &e){ cerr << e.what() << endl; exit(-3); } cout << sl << endl; lst zlist; for(i=0; i<vs.nops(); i++){ zlist.append(vs.op(i)==0); } ex result; result=s.subs(sl).subs(zlist); cout << result << endl; archive a; a.archive_ex(result, "result"); char fname[80]; sprintf(fname, "fixedpoints%d.gar", maxcoeff); ofstream out(fname); out << a; out.close(); }

2 3