- GiNaC-devel - ginac.de

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

:-)
by Richard B. Kreckel 03 Dec '99

03 Dec '99

Aha, I just found this line in the FTP logs: Mon Nov 29 22:38:38 1999 11 ns.maplesoft.on.ca 337437 /pub/GiNaC/GiNaC-0.4.0.tar.bz2 b _ o a mozilla@ ftp 0 * Cheers -richy. -- Richard B. Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

Vacation
by Christian Bauer 30 Nov '99

30 Nov '99

Hi! Just to let you know: I'm away in the time 9.Dec-16.Dec. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/

1 0

A few words about differentiation...
by Richard B. Kreckel 29 Nov '99

29 Nov '99

As everybody knows we don't have inert differentiation like Maple has for instance (lprint(diff(f(x),x)); returns diff(f(x),x) there), we are always applying the full chain rule, end of story. :-/ If a function does not know how to be differentiated it may throw an exception instead, this is acceptable. However, when trying to implement differentiation for the polygamma functions psi(n,x) I ran into a problem with that policy since differentiating wrt the first argument doesn't make much sense there (it's normally just an integer parameter). But when one differentiates wrt x, what happens is this (function::pdiff is the partial differentiation): psi(n,x).diff(x) -> pdiff(psi,0)*n.diff(x) + pdiff(psi,1)*x.diff(x) so differentiation wrt n comes in again through the back door. I have worked around this problem by changing function::diff(). In the above case it would see that n.diff(x).is_zero() and then refrain from trying to compute pdiff(psi,0). It seems to work so far. In ginsh, this allows me to write: > diff(psi(1,x),x); psi(2,x) > diff(psi(n,x),x); psi(n+1,x) > diff(psi(n,x),n); cannot diff psi(n,x) with respect to n Any objections? (It's in CVS, for those of you who have access to it.) So, once more we can live without inert differentiation, let's see how long... On another note: who has implemented atan2::diff() and why didn't it return something slightly simpler (i.e. x/(x^2+y^2) instead of 1/x/(1+y^2/x^2))? Is there some reason for this?? Did I break anything??? Cheers -rbk. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

libginac and binary compatibility
by Christian Bauer 29 Nov '99

29 Nov '99

Hi! Here is an article that explains some of the issues involved in binary compatibility for C++ libraries: http://www-classic.be.com/aboutbe/benewsletter/Issue79.html#Insight I don't propose that we adopt their solution to the problem because as GiNaC is an open source project, it's easier for users to upgrade to a current GiNaC version. But it's nice to know which chanegs to GiNaC will break binary compatibility (and will require resetting the INTERFACE_AGE and BINARY_AGE variables in configure.in). Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/

1 0

hottest website around...
by Alexander Frink 25 Nov '99

25 Nov '99

Check this out: http://www.ginac.de -- Alexander Frink E-Mail: Alexander.Frink(a)Uni-Mainz.DE Institut fuer Physik Phone: +49-6131-393391 Johannes-Gutenberg-Universitaet D-55099 Mainz, Germany

4 6

How to use automake
by Christian Bauer 25 Nov '99

25 Nov '99

Hi! After changing 'configure.in', 'acconfig.h' or 'acinclude.m4' you should run $ aclocal; autoheader; autoconf; automake I suggest that you do this on squark because it has newer versions of autoconf and automake. After changing one of the 'Makefile.am' files you should run $ automake; ./config.status at the top level (i.e. the directory where 'configure.in' lies). 'automake' will generate the 'Makefile.in's and 'config.status' will recreate the Makefiles according to your last configuration (this assumes that you didn't change 'configure.in' or did a 'make distclean' in which case you must re-run 'configure'). These should be the only configuration-related files which you can edit. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/

1 0

Namespaces for GiNaC and xloops
by Christian Bauer 23 Nov '99

23 Nov '99

Hi! GiNaC and libxloops are now put into their own namespaces ("GiNaC" and "xloops", respectively). If you're using GiNaC/libxloops in your own programs, it should be enough to add using namespace GiNaC; using namespace xloops; after the #include <ginac/ginac.h> or #include <lib/xloops.h> to make things compile again. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/

4 5