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/>
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/
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/>
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/
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/
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/
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.htmlhttp://webs.intracom.net.lb/nsbaaklini/pacs.html
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/
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/