- GiNaC-devel - ginac.de

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

Consider this...
by Richard B. Kreckel 31 Oct '99

31 Oct '99

ginsh - GiNaC Interactive Shell V0.3 Copyright (C) 1999 Johannes Gutenberg Universitaet Mainz, Germany This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details. > (1+x)*(1-I); 1-I*x+1-I > print("); type=3add, hash=1 (0x1), flags=3, nops=2 x (symbol): serial=2, hash=0 (0x0), flags=3 1-I (numeric): hash=2147483649 (0x80000001), flags=11 ----- overall_coeff 1-I (numeric): hash=2147483649 (0x80000001), flags=11 =====

2 1

ginsh symbols example
by Christian Bauer 25 Oct '99

25 Oct '99

Hi! Just a (short?) example on how symbols now behave in ginsh after the latest modifications to GiNaC and ginsh: ghost:~/projects/ginsh$ ./ginsh ginsh - GiNaC Interactive Shell V0.3 Copyright (C) 1999 Johannes Gutenberg Universitaet Mainz, Germany This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details. > expand((a+b)^2); expand(('a'+'b')^2); a^2+b^2+2*b*a a^2+b^2+2*b*a > a=2; b=-3; 2 -3 > expand((a+b)^2); expand(('a'+'b')^2); 1 a^2+b^2+2*b*a > x=a+b; y='a'+'b'; -1 b+a > x; 'x'; y; 'y'; -1 x -1 y > print(x); print('x'); print(y); print('y'); -1 (numeric): hash=2147483649 (0x80000001), flags=11 x (symbol): serial=8, hash=10 (0xa), flags=3 -1 (numeric): hash=2147483649 (0x80000001), flags=11 y (symbol): serial=13, hash=10 (0xa), flags=3 > eval(x); eval('x'); eval(x,1); eval('x',1); -1 -1 -1 -1 > eval(y); eval('y'); eval(y,1); eval('y',1); -1 -1 -1 a+b > expand(x^2); expand('x'^2); 1 x^2 > expand(y^2); expand('y'^2); 1 y^2 > unassign('a'); unassign('b'); a b > x; 'x'; y; 'y'; -1 x a+b y > print(x); print('x'); print(y); print('y'); -1 (numeric): hash=2147483649 (0x80000001), flags=11 x (symbol): serial=8, hash=10 (0xa), flags=3 type=3add, hash=0 (0x0), flags=3, nops=2 a (symbol): serial=2, hash=376325877 (0x166e46f5), flags=11 1 (numeric): hash=2147483649 (0x80000001), flags=11 ----- b (symbol): serial=5, hash=659577159 (0x27505947), flags=11 1 (numeric): hash=2147483649 (0x80000001), flags=11 ===== y (symbol): serial=13, hash=10 (0xa), flags=3 > eval(x); eval('x'); eval(x,1); eval('x',1); -1 -1 -1 -1 > eval(y); eval('y'); eval(y,1); eval('y',1); a+b a+b a+b a+b > expand(x^2); expand('x'^2); 1 x^2 > expand(y^2); expand('y'^2); a^2+b^2+2*b*a y^2 > quit Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/

5 9

cint
by Alexander Frink 22 Sep '99

22 Sep '99

Hi, I just wanted to keep you in touch with the cint (C/C++ interpreter) news. The latest version was delayed one week because Mr. Goto used a wrong FTP client which messed up the file name :-( Two of the bugs I reported are fixed, one is still around, and after two minutes I found a new one: typedef vector<T> Tvec; typedef vector<Tvec> Tvecvec; // gives an error class TTvec : public Tvec {}; typedef vector<TTvec> TTvecvec; // works Hopefully this is not too hard for Goto to fix. -- Alexander Frink E-Mail: Alexander.Frink(a)Uni-Mainz.DE Institut fuer Physik Phone: +49-6131-393391 Johannes-Gutenberg-Universitaet D-55099 Mainz, Germany

1 0

Theory symbolic computing (fwd)
by Dirk Kreimer 20 Sep '99

20 Sep '99

---------- Forwarded message ---------- Date: Mon, 20 Sep 1999 06:03:41 +0300 From: "Nazir S. Baaklini" <nsbaaklini(a)intracom.net.lb> To: dirk.kreimer(a)uni-mainz.de Subject: Theory symbolic computing Professor Nazir S. Baaklini, Dhour el Choueir, Lebanon Theoretical Physicist and Symbolic Math Phys Programmer ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dear Dr Kreimer, I had recently developed a new Mathematica package which is quite useful for transparent symbolic manipulations and computations in theoretical physics, particularly classical and quantum field theory, with several applications. I invite you to have a look at anyone of the following equivalent homepages, which would introduce this package and related works. You would also be able to download freely several Mathematica notebooks that would illustrate the various uses of this new program package. http://webs.intracom.net.lb/nsbaaklini http://www.nsbaaklini.homepage.com For additional information and for email: ............................. [ nsbaaklini(a)intracom.net.lb ] ............................. [nsbaaklini(a)usa.net] Yours sincerely, Nazir S. Baaklini

2 2

Tutorial
by Richard B. Kreckel 18 Sep '99

18 Sep '99

The tutorial is now getting into shape. The newest version, including Alexander's chapter about "why on earth?" is now in CVS. Sorry, you still cannot built it yourself. But may I ask to have a quick look at it and comment what is missing or what you would expect from a text that teaches the basic things about GiNaC (and ideally write and contribute it)? For some of you I have put a printed version into the mail boxes, the online version in HTML is sitting at <http://wwwthep.physik.uni-mainz.de/GiNaC/tutorial/>. ¡Hasta la vista! -richy. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

A proposal
by Richard B. Kreckel 17 Sep '99

17 Sep '99

I would like to have some comments from you about a proposal about constants: In order to forbid insane code like this one in GiNaC: EulerGamma = Pi; cout << EulerGamma << endl; // prints 3.14... all objects of class constant need to be declared const (which is the case for built-in constants). While the copy constructor for constants is sane (because when you declare constant EulerGamma(Pi); this is a new constant with local scope) the above case is not. One could override constant::operator= but there are other cases. E.g. I wanted to override constant::subs() to return *this but while this seemlingly worked for the checks it caused basic's virtual table to be overridden with garbage (and then executed, which caused a SEGV beeing raised) by the xloops check. I do not have any clue why this happens. Also, I had to change symbol::subs to be somewhat more flexible. The whole trouble is IMHO caused by the fact that symbol is currently partly caring for its derived class constant. Can't we just eliminate class constant and declare global symbols like Pi, EulerGamma and the like and assign them an evalf()-function similar to how expressions may be assigned to symbols? Then just declare those special symbols const and that's it? I haven't tried it, just wanted to hear your comments and sleep a night before doing something, maybe it's rubbish! Cheers -rbk. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

3 8