- GiNaC-devel - ginac.de

normal(), numer(), denom()
by Christian Bauer 10 Feb '00

10 Feb '00

Hi! normal(), numer(), and denom() should work better now. normal() internally maintains a split representation {numerator, denominator} of the normalized expressions and will not divide them until the very end. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/

1 0

Version 0.5.0 uploaded
by Richard B. Kreckel 08 Feb '00

08 Feb '00

It's on <ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC/>. Many things are fixed now and some sophisticated bugs were substantially improved. As always, the most mind-boggling new features are listed under <http://www.ginac.de/News.html>. Fun and happiness -rbk. PS: Apologies if you got this mail twice. Please do recycle the electrons. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

"Cannot resolve method ex::dbgprint to any overloaded instance" on gdb 4.18
by Richard B. Kreckel 05 Feb '00

05 Feb '00

Hi, Upon multiple request I had a quick look at the subject-mentioned problem that rendered the not-so-useless method dgbprint [1] unavailable. There is nothing to overload here (its argument being void anyhow) so this was kind of obscure. There seems to be a bug introduced in gdb 4.18 and it may already be fixed in the current CVS tree, since Daniel Berlin claims he fixed it a couple of days ago (on the gdb mailing list): > 2. gdb is screwing up the function ranking. Right in the comments it > says that nargs includes the this pointer in it's count, and nparams > doesn't, but it doesn't take this into account. So i made it take it > into account, and all of the sudden, it could resolve overloads > properly in most cases. > I can succesfully do a print AnSTLVector.begin() and AnSTLVector[0], > and if AnSTLVector was a vector of strings, I could do * > (AnSTLVector.begin()).length(), and get the right answer. In the meantime, you may simply tell your debugger to (gdb) set overload-resolution off and you can again build any ex foo and call foo.dbgprint() to display the contents. Those using DDD 3.2 may also set this in Edit->Preferences and save options. HTH -rbk. [1] The method dbgprint(void) is a small wrapper around print(ostream &, unsigned) used for debugging, where cout may not be present. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

Archiving of expressions
by Christian Bauer 19 Jan '00

19 Jan '00

Hi! The long-awaited archiving (aka I/O) of expressions is now implemented in the latest CVS version (except for the classes idx and structure and all classes derived from idx and indexed, because these seem still to be undergoing changes). A new chapter in the tutorial explains how to use the new features. There is now a global registry (implemented in registrar.*) for all archivable classes (= basic and derived classes). To implement archiving for you classes, do the following: - add the GINAC_DECLARE_REGISTERED_CLASS(foo, bar) line to the beginning of the class declaration - add the GINAC_IMPLEMENT_REGISTERED_CLASS(foo, bar) line to the beginning of the *.cpp file of the class - implement the unarchiving constructor and the archive() and unarchive() member functions in your class If your class doesn't add any member variables to its superclass which have to be stored in the archive, you must at least call the unarchiving constructor and the archive() function of the superclass (see add.cpp for an example of how to do this minimal implementation of archiving). If you _do_ have member variables which need to be stored, they have to be added to the archive_node in the archive() function and retrieved from there in the unarchiving constructor (see power.cpp for a simple example, matrix.cpp for a more complex one). The unarchive() function is almost always the same in all classes (for exceptions, see symbol.cpp and constant.cpp). Unarchiving of constants is currently sub-optimal. Only the three constants that we provide (Pi, Catalan, EulerGamma) can be unarchived. A global registry for all existing constants should be implemented. Also, archiving floating-point numbers will lose precision (because they are stored as a decimal fraction). This is being worked on. The small program "viewgar" in the tools directory is a stand-alone viewer for archive files. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/

1 0

Undefined symbols for ginsh
by Jeff Greco 19 Jan '00

19 Jan '00

To Whom It May Concern: I am using: Operating system: SunOS samsun 5.6 Generic_105181-03 sun4u sparc SUNW,Ultra-Enterprise Compiler: egcs-2.91.57 CLN: version 1.0.2 CLN and GiNaC are configured with default settings, except that CLN is only shared libraries. My linker is complaining about undefined symbols in 'ginsh_parser.o'. Any way that you can help is greatly appreciated. Here is the output from make: make all-recursive make[1]: Entering directory `/dumptruck/GiNaC-0.4.1' Making all in ginac make[2]: Entering directory `/dumptruck/GiNaC-0.4.1/ginac' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/dumptruck/GiNaC-0.4.1/ginac' Making all in check make[2]: Entering directory `/dumptruck/GiNaC-0.4.1/check' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/dumptruck/GiNaC-0.4.1/check' Making all in ginsh make[2]: Entering directory `/dumptruck/GiNaC-0.4.1/ginsh' /bin/sh ../libtool --mode=link g++ -g -O2 -o ginsh ginsh_parser.o ginsh_lexer.o ../ginac/libginac.la -lcln -lstdc++ g++ -g -O2 -o .libs/ginsh ginsh_parser.o ginsh_lexer.o ../ginac/.libs/libginac.so -lcln -lstdc++ -lcln -lstdc++ -R/usr/local/lib Undefined first referenced symbol in file rl_basic_word_break_characters ginsh_parser.o rl_readline_name ginsh_parser.o filename_completion_function ginsh_parser.o completion_matches ginsh_parser.o rl_completion_append_character ginsh_parser.o rl_line_buffer ginsh_parser.o rl_attempted_completion_function ginsh_parser.o ld: fatal: Symbol referencing errors. No output written to .libs/ginsh collect2: ld returned 1 exit status make[2]: *** [ginsh] Error 1 make[2]: Leaving directory `/dumptruck/GiNaC-0.4.1/ginsh' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/dumptruck/GiNaC-0.4.1' make: *** [all-recursive-am] Error 2 Thanks, Jeff Greco Jgreco(a)siichi.com

2 1

ToDo-list
by Richard B. Kreckel 12 Jan '00

12 Jan '00

Good morging, Higher forces (drunken collegues) have just urged me to send this mail to the list: ;*) Today I have written a little summary about possible future extensions of GiNaC accessible at <http://www.ginac.de/ToDo.html>. Feel free to comment on it. regards -rbk. PS: I have been wondering for a while about ASSERT. Don't we need two different kinds of assertions? One for things within the library like the GINAC_ASSERT(is_canonical()); at line 94 in ginac/mul.cpp and one like the GINAC_ASSERT(is_exactly_of_type(other, matrix)); at line 255 in matrix.cpp? (Both lines refer to current CVS stuff.) The first one marks an oops that can only happen to developers of the library, the second can happen to anybody. In a distribution, the first one may be ommitted from the normal runtime-library, but not the second, which may not even be fatal but only issue a warning. Maybe we do need a soft and a hard ASSERT??? -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

2 1

GiNaC porting status
by Richard B. Kreckel 10 Jan '00

10 Jan '00

I once wrote about 64-bit issues and that GiNaC builds fine on Linux/AXP except for shared libraries, where everything segfaulted immediately. Somebody guessed we were suffering from some "static initialization order fiasco". I haven't looked into that since then---which is good, since I just came across this quote from the current GCC caveats list <http://gcc.gnu.org/gcc-2.95/caveats.html>: : Exception handling may not work with shared libraries, particularly on : alphas, hppas, rs6000/powerpc and mips based platforms. Exception : handling is known to work on x86 GNU/Linux platforms with shared : libraries. So, it's not our problem, is it? Doesn't sound good, though. Happy hacking -rbk. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

porting status (bad news)
by Richard B. Kreckel 23 Dec '99

23 Dec '99

Ok, here is a little update on what's happening when you dare to use GCC 2.96. Actually, I'm talking about the current CVS-snapshot, which claims to be 2.96 according to __GNUC__ and __GNUC_MINOR__. (And, yes, I have tried the last two *official* snapshots too.) First of all, CLN has to be recompiled because otherwise it aborts at each exception thrown. (This is business as usual, I don't know why this is so and have asked B. Haible for a hint.) If one tries, one runs into problems because the new compiler complains: `void () ()' cannot be `const'-, `volatile'-, or `restrict'-qualified I have made a quick hack around this problem in cl_macros.h but then one runs into trouble again with internal compiler errors, always in `scan_region', at except.c:2710 on different CLN-modules. (Bugreport for gcc-bugs is already submitted.) One can get around this problem by fiddling with optimization options but this does not seem to built a useful library then, since it sometimes fails at some of the random checks. :-( If one insists and builts GiNaC, ginsh and whatnot against this library it fails at every test once optimization is switched on. Omitting optimization results in the follwing fiasco: checking several ex-bugs just out of pure paranoia... failed (NaNs) checking output of numeric types... passed (0.03s) checking consistency of numeric types... passed (0.04s) checking power laws... passed (NaNs) checking commutative expansion and substitution... passed (NaNs) checking consistency of symbolic functions... failed (NaNs) checking symbolic differentiation... passed (NaNs) checking polynomial GCD computation... passed (NaNs) checking rational function normalization... passed (NaNs) checking symbolic matrix manipulations... passed (NaNs) checking linear solve... passed (NaNs) checking series expansion... passed (NaNs) error: something went wrong. (2 individual failures) please check result.out against result.ref for more details. happy debugging! Comparing output... result.ref result.out differ: char 53, line 2 FAIL: run_checks =================== 1 of 1 tests failed =================== make[2]: *** [check-TESTS] Error 1 make[2]: Leaving directory `/home/kreckel/projects/GiNaC/check' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/home/kreckel/projects/GiNaC/check' make: *** [check-recursive] Error 1 higgsino:~/projects/GiNaC$ diff check/result.out check/result.ref 2c2 < e = x*y*z; f = y*z; expand(e/f) erroneously returned x --- > (no output) 16c16 < sin(n*Pi) with integer n does not always return exact 0 --- > (no output) Both error-reports are *logically* wrong (the first one is obvious). Also, the NaN seconds are quite funny, they go away as soon as one tries to trace down their origin. Holy shit, GCC seems to be rather broken at present. The good news is that the more restrictive preprocessor didn't find any mistakes in GiNaC itself. Happy hacking -rbk. PS: No, my system's clock is fine. :-( -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

collect() bug
by Christian Bauer 20 Dec '99

20 Dec '99

Hi! Consider this: > collect((1-t^2)/(1+t),t); (t+1)^(-1) This is clearly wrong... Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/

2 1

Version 0.4.1
by Richard B. Kreckel 14 Dec '99

14 Dec '99

Hello all, Apologies if you got this mail twice, but the set of people on ginac-list and ginac-devel is neither disjoint nor is one a subset of the other... This is to notify you that we've uploaded version 0.4.1 of GiNaC yesterday. The updated documentation is sitting on <http://www.ginac.de/> as well. Please read the News if you are curious on what has changed (it ain't anything dramatic). Check it out, test it, submit bug-reports and (if possible) fixes! Just to keep people informed about current development, let me mention that the next release will probably feature an interface to the CINT C++ interpreter <http://root.cern.ch/root/Cint.html> by Masaharu Goto. This will allow people to write C++ scripts interactively and to compile them later. We'll get another interactive interface to GiNaC besides ginsh this way---one with all loop constructs, conditionals and containers known from C++. Currently there are still some weirdnesses concerning automatic promotion of types which are hopefully fixed soon but we are already quite excited about the new possibilities. happy hacking -rbk. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0