- GiNaC-devel - ginac.de

Version 0.5.3 on the wire
by Richard B. Kreckel 24 Feb '00

24 Feb '00

i.e. on <ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC/>. There has been a bug in the last version where .normal() was returning wrong results for certain rational functions like 1/(5-4*a)*(-5-2*a-(3+2*a)*(2-5*a)/(-2+a)) which is now fixed. Also, this version features an improved and more flexible scheme for registering functions which makes extensions easier and also allows writing remembering functions in a clean way. See <http://www.ginac.de/reference/class_remember_table.html>. GiNaC-cint is making slow progress---we have it running with the current cint 5.14.31 now. Sex and drugs and Unix -rbk. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

Build problems
by Patrick K Notz 22 Feb '00

22 Feb '00

Hi, I'me trying to build ginac and am having problems getting 'configure' to find the readline and cln libraries. I've installed them in directories (non-standard since I'm not root) under my account. I just can't figure out how to tell configure/make to look there. I've tried the suggestion in Section 3.2 of the tutorial but the syntax given doesn't work. I've tried adding "LDFLAGS = $(LDFLAGS) /my/lib/dir" to all of the Makefile.in files but no luck again. I'm not familiar with autoconf so I'm not sure which files I should try tweeking. Can you offer any suggestions? Thanks ~ pat <notz(a)purdue.edu>

2 1

Today's bugs
by Richard B. Kreckel 21 Feb '00

21 Feb '00

Consider this: higgsino:~/projects/GiNaC/ginsh$ ./ginsh ginsh - GiNaC Interactive Shell (GiNaC V0.5.2) __, _______ Copyright (C) 1999-2000 Johannes Gutenberg University Mainz, (__) * | Germany. This is free software with ABSOLUTELY NO WARRANTY. ._) i N a C | You are welcome to redistribute it under certain conditions; <-------------' see the file COPYING for details. Type ?? for a list of help topics. > series(gamma(x),x,0,2); collect(series(gamma(x),x,0,2),x); -EulerGamma+x*(1/12*Pi^2+1/2*EulerGamma^2)+x^(-1)+Order(x^2) -EulerGamma+x*(1/12*Pi^2+1/2*EulerGamma^2)+x^2*Order(1)+x^(-1) The other bug is with the fraction free elimination in ginac/matrix.cpp: If I try to solve the system [[ [[0,2-a]], [[5-4*a,3+2*a]] ]] * [[ [[x]], [[y]] ]] == [[ [[-2+5*a]], [[-5-2*a]] ]] I run into trouble within assert-blocks. I will have a look at the second problem. -rbk. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

3 3

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