November 1999 - GiNaC-devel

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

Fun from Lebanon
by Alexander Frink 19 Nov '99

19 Nov '99

I think we just stop giving away GiNaC for free and sell it like others do with their symbolic software (vaporware?)... -- Alexander Frink E-Mail: Alexander.Frink(a)Uni-Mainz.DE Institut fuer Physik Phone: +49-6131-393391 Johannes-Gutenberg-Universitaet D-55099 Mainz, Germany ---------- Forwarded message ---------- Date: Fri, 19 Nov 1999 10:15:07 +0200 From: "Nazir S. Baaklini" <nsbaaklini(a)intracom.net.lb> To: Alexander.Frink(a)Uni-Mainz.DE Subject: Your opinion Dear Alexander Frink, I would appreciate your opinion regarding whether academic and research scholars such as professors and students shouldn't be interested in an advanced symbolic computational package for theoretical physics at the level described and demonstrated on my web sites addressed below. In particular, I would like to benefit from your suggestion regarding the pricing of such a package, especially that I am about to announce several new applications of this package for the new year... Gratefully yours, Professor Nazir S. Baaklini http://www.nsbaaklini.homepage.com/pacs.html http://webs.intracom.net.lb/nsbaaklini/pacs.html

1 0

GiNaC coding standards :-)
by Christian Bauer 10 Nov '99

10 Nov '99

Hi! - The main file to include for programs using GiNaC is <ginac/ginac.h>. This file will include all other public GiNaC headers in the proper order. - No public GiNaC header file should include other GiNaC header files. - GiNaC source files should include "ginac.h" and (optionally) "config.h" and other private GiNaC header files. - All GiNaC-related source files have a header that is structured like this: /** @file <file name> * * <description> * * <copyright> * * <GNU disclaimer> */ Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/

1 1

GiNaC even more restructured
by Christian Bauer 09 Nov '99

09 Nov '99

Hi! I've converted the GiNaC sources to use the "automake" tool. This involved several changes: - created "Makefile.am" files - added several support files: "config.guess", "config.sub", "install-sh", "missing", "mkinstalldirs", "ltconfig", "ltmain.sh" - "src" directory renamed to "ginac" and moved header files from "include" to "ginac", removed the "include" directory (it is easier to build and install GiNaC with automake if things are arranged this way) Doing a "cvs update -P GiNaC" should get you the new files (and remove the obsolete ones). I have tested "configure", "make", "make check", "make install", "make install-strip", "make uninstall", "make clean", "make distclean" and "make maintainer-clean" and they seem to work. I haven't tried whether the package created by "make dist" actually works. Misc notes: - The configuration files which are supposed to be edited manually are the "Makefile.am" files, "acconfig.h", "acinclude.m4" and "configure.in". All other config files like the "*.in" files are generated by automake&Co. - More specifically: - acinclude.m4 -> aclocal.m4 by aclocal - configure.in -> configure by autoconf - acconfig.h -> config.h.in by autoheader - Makefile.am -> Makefile.in by automake - The version of the shared libginac.so is not set correctly. - Both static and shared library version are built by default. Say "configure --disable-shared" to only build the static library (makes for quicker development). - Saying "make" at the top level will build everything (libginac, ginsh, check, doc). To only recompile libginac, cd to "ginac" and say "make" there. - The automake-generated makefiles automatically store dependency information in hidden ".deps" directories. - The doc/Makefile.am is empty as of yet. Don't worry, I've saved the old doc/Makefile.in and will integrate this later. - The files "AUTHORS", "ChangeLog", "NEWS" and "README" have to be filled with something reasonable. Supposedly, CVS is able to create "ChangeLog" files, but I haven't yet found out how. - The official top-level header to include for programs using GiNaC is now <ginac/ginac.h>. - Ideally, all include files which go to /usr/include/ginac should be designed to not include themselves mutually. The top-level <ginac/ginac.h> should include all of them in the right order. - Also, our include files should #define __GINAC_ADD_H__ instead of #define _ADD_H_ to avoid possible conflicts with user include files. - We should probably include the GNU standard disclaimer at the top of all sources and headers. - For more information, please refer to the automake and autoconf docs, and to the GNU Coding Standards - I will try to fix the abovementioned bugs and "automakeify" xloops tomorrow. I hope I didn't cause too much confusion... :-) Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/

1 0

GiNaC restructured
by Richard B. Kreckel 08 Nov '99

08 Nov '99

Most of you know already that we have restructured the GiNaC sources. It is now split into some more subdirectories and the Ginac INteractive SHell ginsh is now part of the dirstribution. Please, spent some lighter fluid to burn all your old GiNaC and xloops stuff (maybe make a backup copy for nostalgic reasons) because we have completely erased CVSROOT and set up new repositories for GiNaC and xloops. You may check out these, then. Happy bug-hunting -richy. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0