- GiNaC-devel - ginac.de

Release 0.9.4 just hit the net
by Richard B. Kreckel 21 Sep '01

21 Sep '01

Okay, that's it. No 500M$ unveiling event for this release of GiNaC, we're afraid, but you are still welcome to go out in the streets and deliver this message of joy to the masses: * Functions have better support for external scripting languages. * Interface cleanups and bugfixes. * Fix silly bug in evalf() that prevented things like 2^Pi being computed. Cheers -richy.

1 0

Code-Analysis of the day: the potential of __builtin_expect()
by Richard B. Kreckel 19 Sep '01

19 Sep '01

Just discovered the Linux kernel folks are starting to use this fancy new feature of GCC-3.0 (and also the triple-cursed GCC-2.96) at some places. It lets us give the compiler a hint which branch is expected to be taken. I found that it indeed does increase performance, even on Intel where it cannot do much more than reordering the code. The simplest example is ex's dtor: inline ex::~ex() { if (--bp->refcount==0) delete bp; } which, using GCC-3.0.1, compiles to (CXXFLAGS="-O2"): 00000000 <GiNaC::ex::~ex()>: 0: 55 push %ebp 1: 89 e5 mov %esp,%ebp 3: 83 ec 08 sub $0x8,%esp 6: 8b 45 08 mov 0x8(%ebp),%eax 9: 8b 10 mov (%eax),%edx b: 8b 42 10 mov 0x10(%edx),%eax e: 48 dec %eax f: 85 c0 test %eax,%eax 11: 89 42 10 mov %eax,0x10(%edx) 14: 74 0a je 20 <GiNaC::ex::~ex()+0x20> 16: 89 ec mov %ebp,%esp 18: 5d pop %ebp 19: c3 ret 1a: 8d b6 00 00 00 00 lea 0x0(%esi),%esi 20: 85 d2 test %edx,%edx 22: 74 f2 je 16 <GiNaC::ex::~ex()+0x16> 24: 8b 02 mov (%edx),%eax 26: 83 ec 0c sub $0xc,%esp 29: 52 push %edx 2a: ff 50 0c call *0xc(%eax) 2d: 83 c4 10 add $0x10,%esp 30: eb e4 jmp 16 <GiNaC::ex::~ex()+0x16> Using quite expressive macros(*) lifted from the kernel, we can try to pessimise the code by saying that deletion is going to be likely (it isn't): inline ex::~ex() { if (likely(--bp->refcount==0)) delete bp; } Under the same compilerflags as above we now get the slightly shorter section: 00000000 <GiNaC::ex::~ex()>: 0: 55 push %ebp 1: 89 e5 mov %esp,%ebp 3: 83 ec 08 sub $0x8,%esp 6: 8b 45 08 mov 0x8(%ebp),%eax 9: 8b 10 mov (%eax),%edx b: 8b 42 10 mov 0x10(%edx),%eax e: 48 dec %eax f: 85 c0 test %eax,%eax 11: 89 42 10 mov %eax,0x10(%edx) 14: 75 10 jne 26 <GiNaC::ex::~ex()+0x26> 16: 85 d2 test %edx,%edx 18: 74 0c je 26 <GiNaC::ex::~ex()+0x26> 1a: 8b 02 mov (%edx),%eax 1c: 83 ec 0c sub $0xc,%esp 1f: 52 push %edx 20: ff 50 0c call *0xc(%eax) 23: 83 c4 10 add $0x10,%esp 26: 89 ec mov %ebp,%esp 28: 5d pop %ebp 29: c3 ret However, as expected, this runs slower (approx 5%!) than the version without the misleading compiler hint. It's quite interesting how the blocks were reordered in this example. A good compiler hint would be: inline ex::~ex() { if (unlikely(--bp->refcount==0)) delete bp; } This, however, compiles to the same code as the one without any hint. Interesting. I tried to insert similar hints at several places where it appears clear that I should know better than the compiler what is likely going to happen next. It always turned out to produce the same code. Why is the compiler is so good at making the right decision? I found that I always was introducing unlikely(), never likely(). Is a branch implicitly assumed as not taken??? Anyways, this stuff seems to be a bit premature. I just record it here in case somebody wants to experiment with this stuff. Regards -richy. (*) The exact definition was lifted from kernel-2.4.10-pre11: #define likely(x) __builtin_expect(!!(x), 1) #define unlikely(x) __builtin_expect((x), 0) -- Richard B. Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

Cint status update
by Richard B. Kreckel 14 Sep '01

14 Sep '01

Hi, Since Cint release 5.15.09, which happened 5 weeks ago, GiNaC and Cint have come to terms again and can happily co-exist. The handful of bugs in Cint that prevented successful compilation with GiNaC version >= 0.9.0 have all been fixed now. For those of you who want to give it a try, I have just fixed a few very minor issues in ginaccint and uploaded version 1.0.1 to the usual place, i.e. to <ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC/ginaccint/>. Regards -richy. -- Richard B. Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

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