- GiNaC-devel - ginac.de

bug(?): psi() Aborts
by Pearu Peterson 21 Nov '01

21 Nov '01

Hi, Notice that the following program #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; int main() { numeric x("2"); cout << "psi("<<x<<")="<<psi(x) << endl; return 0; } just Aborts when running it (when replacing psi->sin, it runs fine). Does it happen to you? I am using ginac-1.0.0 (from a week old CVS) cln-1.1.3 gmp-3.1.1, gcc version 2.95.4 20011006 (Debian prerelease) on woody debian. Any ideas what is wrong with calling psi? Btw, when when running `make ginac.html' in tutorial, it just generates ginac directory but not the file ginac.html. Pearu

2 1

relational::operator bool()
by Douglas Gregor 16 Nov '01

16 Nov '01

Hello, This is just a C++ nitpick, but operator bool() is often considered harmful because of the plethora of implicit conversions (bool->int being the worst of these implicit conversions, IMHO). I'm not suggesting that operator bool() be removed from relational, but instead replace it with a safer construct. Within the Boost C++ libraries (http://www.boost.org) we've adopted a "safe_bool" conversion using of a pointer-to-member function. The trick can be illustrated concisely: // Add to class relational private: struct dummy { void nonnull() {}; }; typedef void (dummy::*safe_bool)(); safe_bool make_safe_bool(bool cond) const { return cond? &dummy::nonnull : 0; } Then in relational::operator safe_bool() const, whereever there is a "return <bool-expression>", it should be replaced with "return make_safe_bool(<bool-expression>)". The use of the pointer-to-member function eliminates implicit conversions, but the relational class can still be used in a boolean context (since it is evaluated as "is the pointer-to-member function null?"). All meaningless operations that are allowed by a "bool" conversion except for == and != are eleminated by this "safe_bool". I can submit a patch against CVS if needed. Doug Gregor gregod(a)cs.rpi.edu

2 5

Infinity and Undefined
by Douglas Gregor 15 Nov '01

15 Nov '01

Hello all, I'm currently extending GiNaC to be used for symbolic range propagation. While the specifics of the extensions are likely not interesting to most users, I do find that I need to handle both Infinite and Undefined values in a sensible manner. I'll describe the approach I've taken thus far and would appreciate feedback. Including Infinity and Undefined within GiNaC seems to weed its way into many areas of the code. For instance, when we have two expair's x and y, we assume that if x->rest == y->rest we can combine the coefficients. Clearly this doesn't hold when we consider Infinity or Undefined, so we end up with a large number of special-case branches when we see Infinity or Undefined in an expression. This happens in quite a few places. My current approach is to defined GiNaC::constant values for Infinity and Undefined, and include functions to quickly check if an expression is the Infinity or Undefined constant. From there we just need to find all of the required special cases... Again, and feedback would be appreciated. I've only been using GiNaC for a short while, and perhaps there are tricks that could make this addition go more smoothly. Doug Gregor gregod(a)cs.rpi.edu

3 6

Breaking News
by Richard B. Kreckel 06 Nov '01

06 Nov '01

MAINZ, Germany, November 6, 2001 (for immediate release) The GiNaC hackers, the leading providers of advanced mathematical software solutions for research and industrial applications, loudly announce the availability of GiNaC version 1.0. GiNaC stands for "GiNaC is not a CAS", i.e. not a Computer Algebra System. This is reminiscent to the term GNU, which stands for "GNU is not Unix", yet GNU systems widely define Unix today. It is a C++ class-library that allows certain common symbolic manipulations to be expressed directly in that language. "This release is going to change a whole lot of things" says Richard Kreckel, vice president of GiNaC's PR department. "Competing closed-source systems like Mathematica and Maple must be considered obsolete now and will surely soon fall into oblivion -- Macsyma already has." Asked whether GiNaC can really compete with all the fancy features and gimmicks found in those systems he replied: "Hey, there is always room for version 2.0 and the next generation!" Alexander Frink, vice president of GiNaC's sales department, could not be reached for a statement. He was reckoned to be busy encashing donations from millions of joyous users overwhelmed with enthusiasm. GiNaC is free software and licensed under the GNU general public license (GPL). "Having a truly scalable symbolic system is going to solve many of todays problems" says Christian Bauer, vice president of the research and development department. "Applications range from pure maths and physics over geological surveys, long-term stock options and wheather forecasts to such fields as wine-making and Japanese cuisine." The newly released version 1.0 contains "absolutely no significant changes relative to the last version whatsoever" according to Bauer. Asked how he sees further development he crypticly proclaimed "We are simply going to do what we did with the Macintosh: We emulate all other systems, including their bugs." Instructions how to download and install GiNaC on a computer system can be found at <http://www.ginac.de/Download.html>. Also, it comes pre-bundled with several distributions of the popular Linux operating system as well as with FreeBSD. Because of this dominant position on the consumers' computer desktops the US department of justice (DOJ) is considering filing an antitrust law-suit. "Okay, Microsoft got away with this practice, but we are not going to tolerate imitators", said DOJ attorney general John Ashcroft at a meeting with press. Germany's foreign minister Joschka Fischer delayed his trip to meet Palestinian president Jassir Arafat to stop in Mainz and congratulate the GiNaC folks for their release on behalf of Germany's chancellor Gerhard Schroeder. IT-industry friendly Mr. Schroeder was said to be busy "getting the beast installed" on his PC. "This new release is going to have a tremendous impact on global stability" Mr. Fischer said. "We have observed how politicians and suspected terrorists alike have become addicted to GiNaC and been converted to coding machines -- in a noble sense. Wherever they find a PC they start emitting mesmeric steams and then the miracle of code generation happens."

1 0

RE:templates and builtin functions
by Richard B. Kreckel 02 Nov '01

02 Nov '01

Dear Masaharu, On Fri, 2 Nov 2001, Masaharu Goto wrote: > 1. Do you really need to compile above template function? > 2. Or can you accept that this one being interpreted? > > In case of 1. , it is unfortunate I see no solution. In case of 2. > I think it is as simple as to load template source file at run time. > > Or do I still miss something? If so, I will review your message again. > I spent only a few minutes reading it... No, you are not missing something. I probably was. Having this interpreted rather than precompiled is obviously the Right Thing (tm). Thanks for your clarifying comments. Now, given a header file containing only the definition template<typename T1> inline const GiNaC::function cosh(const T1 &p1) { return GiNaC::function(GiNaC::function_index_cosh, GiNaC::ex(p1)); } in the GiNaC-Cint interface I can write: Welcome to ginaccint V1.0.1 (GiNaC V0.9.9, Cint V5.15.10) __, _______ GiNaC: (C) 1999-2001 Johannes Gutenberg University Mainz, (__) * | Germany. Cint C/C++ interpreter: (C) 1995-2001 Masaharu ._) i N a C | Goto and Agilent Technologies, Japan. This is free software <-------------' with ABSOLUTELY NO WARRANTY. For details, type `.warranty' Type `.help' for help. >> #include "testheader_cintfunction.h" >> //ginaccint.function next expression can be a function definition >> ex EulerNumber(unsigned n) > { > const symbol xi; > const ex generator = pow(cosh(xi),-1); > return generator.diff(xi,n).subs(xi==0); > } creating file /tmp/ginacbt5aGZ >> cout << EulerNumber(60) << endl; 18108911496579230496545807741652158688733487349236314106008095454231325 >> quit; removing file /tmp/ginacbt5aGZ I am almost happy. There are just the following problems left: 1) I cannot just #include <ginac/function.h> and <ginac/inifcns.h>, where such things are declared. This is because Cint doesn't really seem to be #including them. Probably because it has already done so while ginaccint was compiled and the include guards of these header files are still active. I think I can work around this problem by simply #undef'ing the include guards and reloading those two headers in some automatic way. First attempts look promising... 2) ...but resolution of the proper function is still not correct in Cint! Consider cosh as above, but now sitting in namespace GiNaC: >> cout << GiNaC::cosh(1) << endl; // this is clear cosh(1) >> cout << cosh(1) << endl; // one could say this should be ambigous 1.54308 >> using GiNaC::cosh; >> cout << cosh(1) << endl; // now it should be clear, but it really called... 1.54308 >> cout << std::cosh(1) << endl; // ...this one. :-( 1.54308 Could using declarations like the above one be properly supported by Cint?!? As an aside, why does G__cpp_whatever.h #include <math.h>? Is this really needed? (I seem to be able to just delete it prior to comiling G__cpp_whatever.cpp). Regards -richy. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

Recent CVS commit
by Richard B. Kreckel 22 Oct '01

22 Oct '01

Hi, I just committed into CVS a major change how frequent numeric objects (`flyweights') are set up. Until now we had functions like `const ex & _ex1(void)' that always returned the same ex representing numeric 1. This speeds up the library considerably because ex::compare can be restricted to pointer comparison. However, the object inside that function was constructed on first use of the function as a static variable and thus came the two thorns in my side: 1) Ugly syntax: Several hundreds of occurrences of _ex0(), _ex1(), etc, resulting in fishbone Lisp-style. 2) The function call occuring there could not be avoided, resulting in degraded speed. I have now figured a way how to avoid these problems. Similarly to section 27.4.2.1.6 in the C++ standard, where cout and friends are set up, we now allocate a static initializer object in each object file #include'ing <ginac/ex.h>. The first of these constructors being called takes care of setting up the flyweights `const numeric *_num1_p' on the heap and marking them as `dynallocated' [*]. Then, in file utils.cpp, we initialize both const numeric &_num1 = *_num1_p; const ex _ex1 = _num1; Wherever we have been writing _ex1() we can thus simply write _ex1 internally. Same applies to _num1() which is now called _num1. As advertised, the change makes parts of the library more readable and the compiled library slightly smaller and about 5-15% faster. I checked that it still works with Cint (5.15.14) and some other unmodified apps. Pearu, could you please check with PyGiNaC? I understand that Python sets up Flyweights from 0 to 100 as well but I cannot see that the two are tied together in any way. Therefore you hopefully aren't affected at all. Regards -richy. [*] This assures ex' ctor from basic& does not copy it again. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

http://www.ginac.de/ deadlink
by keith.briggs＠bt.com 21 Sep '01

21 Sep '01

At http://www.ginac.de/, the link CLN Class Library for Numbers <http://clisp.cons.org/~haible/packages-cln.html> still doesn't work. Can't use GiNaC without CLN! 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

2 1

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