- GiNaC-devel - ginac.de

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-200-g9b5d06b
by git＠ginac.de 04 Oct '09

04 Oct '09

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, master has been updated via 9b5d06b34d3ee5f0ccd3c500be38fcdf61222956 (commit) from ac235fa0a9285c055993bfa019896018db1817e6 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 9b5d06b34d3ee5f0ccd3c500be38fcdf61222956 Author: Richard Kreckel <kreckel(a)ginac.de> Date: Sun Oct 4 22:30:45 2009 +0200 Output LaTeX-symbols using \mathrm, instead of \mbox. Using \mathrm improves printing in complex formulae. One reason is that it scales in fractions. [by Vladimir Kisil] ----------------------------------------------------------------------- Summary of changes: ginac/constant.cpp | 6 +++--- ginac/inifcns.cpp | 4 ++-- ginac/inifcns_gamma.cpp | 2 +- ginac/inifcns_nstdsums.cpp | 6 +++--- 4 files changed, 9 insertions(+), 9 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Powers of exponents
by Vladimir V. Kisil 04 Oct '09

04 Oct '09

Dear All, I noticed that exp() functions is not aware of power() method. As a results simple things like pow(exp(a), 2) are not simplified to exp(2*a). I am attaching the corresponding patch. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/

4 12

[SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-214-g9fb1753
by git＠ginac.de 04 Oct '09

04 Oct '09

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, ginac_1-5 has been updated via 9fb17531da05d2959decc3856d03c71c0220b116 (commit) from 43d36593b9588b938a42a98f823c36c9f1ded088 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 9fb17531da05d2959decc3856d03c71c0220b116 Author: Jens Vollinga <jensv(a)nikhef.nl> Date: Sun Oct 4 22:15:13 2009 +0200 Moved header includes to source files to avoid polluting the namespace for library users. ----------------------------------------------------------------------- Summary of changes: ginac/parser/default_reader.tpl | 7 +++++++ ginac/parser/parse_context.h | 6 ------ ginac/parser/parser.cpp | 6 ++++++ 3 files changed, 13 insertions(+), 6 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

[SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-213-g43d3659
by git＠ginac.de 29 Sep '09

29 Sep '09

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, ginac_1-5 has been updated via 43d36593b9588b938a42a98f823c36c9f1ded088 (commit) from f2f67dde5c9caca69137da2178118407f27639ef (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 43d36593b9588b938a42a98f823c36c9f1ded088 Author: Richard Kreckel <kreckel(a)ginac.de> Date: Tue Sep 29 22:28:47 2009 +0200 Remove debian/ directory. The lifecycle of the Debian packaging files is better maintained in the Debian pool's diff file. Removing these files makes the life of the GiNaC releaser easier. ----------------------------------------------------------------------- Summary of changes: debian/changelog | 322 ------------------------------------------- debian/compat | 1 - debian/control | 64 --------- debian/copyright | 27 ---- debian/ginac-tools.install | 5 - debian/ginac-tools.menu | 7 - debian/ginac.xpm | 48 ------- debian/libginac-dev.info | 1 - debian/libginac-dev.install | 6 - debian/libginac1.5.install | 1 - debian/rules | 18 --- 11 files changed, 0 insertions(+), 500 deletions(-) delete mode 100644 debian/changelog delete mode 100644 debian/compat delete mode 100644 debian/control delete mode 100644 debian/copyright delete mode 100644 debian/ginac-tools.install delete mode 100644 debian/ginac-tools.menu delete mode 100644 debian/ginac.xpm delete mode 100644 debian/libginac-dev.info delete mode 100644 debian/libginac-dev.install delete mode 100644 debian/libginac1.5.install delete mode 100755 debian/rules hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-199-gac235fa
by git＠ginac.de 29 Sep '09

29 Sep '09

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, master has been updated via ac235fa0a9285c055993bfa019896018db1817e6 (commit) from b80dafc8692debf6c1d8b6bafb80e30c3ae03f6e (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit ac235fa0a9285c055993bfa019896018db1817e6 Author: Richard Kreckel <kreckel(a)ginac.de> Date: Tue Sep 29 22:25:16 2009 +0200 Remove debian/ directory. The lifecycle of the Debian packaging files is better maintained in the Debian pool's diff file. Removing these files makes the life of the GiNaC releaser easier. ----------------------------------------------------------------------- Summary of changes: debian/changelog | 322 ------------------------------------------- debian/compat | 1 - debian/control | 64 --------- debian/copyright | 27 ---- debian/ginac-tools.install | 5 - debian/ginac-tools.menu | 7 - debian/ginac.xpm | 48 ------- debian/libginac-dev.info | 1 - debian/libginac-dev.install | 6 - debian/libginac1.5.install | 1 - debian/rules | 18 --- 11 files changed, 0 insertions(+), 500 deletions(-) delete mode 100644 debian/changelog delete mode 100644 debian/compat delete mode 100644 debian/control delete mode 100644 debian/copyright delete mode 100644 debian/ginac-tools.install delete mode 100644 debian/ginac-tools.menu delete mode 100644 debian/ginac.xpm delete mode 100644 debian/libginac-dev.info delete mode 100644 debian/libginac-dev.install delete mode 100644 debian/libginac1.5.install delete mode 100755 debian/rules hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

[SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-212-gf2f67dd
by git＠ginac.de 29 Sep '09

29 Sep '09

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, ginac_1-5 has been updated via f2f67dde5c9caca69137da2178118407f27639ef (commit) from 7a2ac48810afb303e1580afb6266876dda3c5da0 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit f2f67dde5c9caca69137da2178118407f27639ef Author: Richard Kreckel <kreckel(a)ginac.de> Date: Tue Sep 29 22:08:11 2009 +0200 Properly document how to deal with libtool versioning. The old description was referring to ginac_lt_age which should always stay 0, because we promised to mark incompatible binary interfaces by bumping ginac_minor_version (or even ginac_major_version). Let's get rid of ginac_lt_age. ----------------------------------------------------------------------- Summary of changes: configure.ac | 24 ++++++++++-------------- 1 files changed, 10 insertions(+), 14 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-198-gb80dafc
by git＠ginac.de 29 Sep '09

29 Sep '09

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, master has been updated via b80dafc8692debf6c1d8b6bafb80e30c3ae03f6e (commit) from 59ec13895c97ffd74979a0b811a7571f6de56386 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit b80dafc8692debf6c1d8b6bafb80e30c3ae03f6e Author: Richard Kreckel <kreckel(a)ginac.de> Date: Tue Sep 29 22:08:11 2009 +0200 Properly document how to deal with libtool versioning. The old description was referring to ginac_lt_age which should always stay 0, because we promised to mark incompatible binary interfaces by bumping ginac_minor_version (or even ginac_major_version). Let's get rid of ginac_lt_age. ----------------------------------------------------------------------- Summary of changes: configure.ac | 20 +++++++++----------- 1 files changed, 9 insertions(+), 11 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Re: [GiNaC-devel] Making new releases: libtool
by Richard B. Kreckel 27 Sep '09

27 Sep '09

Hi Ralf! Ralf Wildenhues wrote: >> Have I added, removed ro changed a function >> or class? I'm not sure. Interface-wise not. But I've changed >> functionality (it doesn't crash any more). So I increment CL_CURRENT >> to 7 and set CL_REVISION to 0. > > Why? I'd only do that if the crash was part of previously documented > behavior, i.e., intentional, and that users of the old version of your > library rely on it crashing, and need to change their code and > recompile/relink to use the new version. If all you've done is a bugfix > then I don't see why your interface has changed. So all you do from the > previous release is bump up CL_REVISION, and not touch the rest. I find the phrase "functions/classes have been changed" rather confusing. It is unclear what "changed" means. > The whole thing is pretty simple if you consider that there are three > possible kinds of reactions from your users to changes from you: > > 1) Programs using the previous version may use the new version as > drop-in and programs using the new version can also work with the > previous one. IOW, no recompiling, no relinking needed. In this case, > bump REVISION only. > > 2) Programs using the previous version may use the new version as > drop-in but Programs using the new version may use APIs not present in > the previous one. IOW, a program linking against the new version may > fail with "unresolved symbols" if linking against the old version at > runtime: REVISION = 0, bump CURRENT and AGE. > > 3) Programs may need to be changed, recompiled, relinked in order to use > the new version. REVISION = 0, bump CURRENT, AGE = 0. > > HTH. We should probably add something like that to the Libtool manual, > but for that I should think about this a bit more, in case I overlooked > something. Thank you! And please add this to the Libtool manual. This explanation is so much easier to understand than the existing one. Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

1 1

Making new releases: libtool
by Richard B. Kreckel 21 Sep '09

21 Sep '09

Hi Ralf! I just figured I would like to make a new release of CLN. I then realized that setting version numbers has always been confusing me. Until now, I've never cared as much about this as I should, but this should some day get clarified. The configure.ac file in CLN says: dnl * increment CL_REVISION, dnl * if any functions/classes have been added, removed or changed, dnl increment CL_CURRENT and set CL_REVISION to 0, dnl * if any functions/classes have been added, increment CL_AGE, dnl * if backwards compatibility has been broken, set CL_AGE to 0. dnl $(CL_CURRENT):$(CL_REVISION):$(CL_AGE) results in dnl libcln.so.$(CL_CURRENT)-$(CL_AGE) Okay, let's see. I've fixed a function that used to segfault and I've added support for a platform that was not supported before. I increment CL_REVISION. Have I added, removed ro changed a function or class? I'm not sure. Interface-wise not. But I've changed functionality (it doesn't crash any more). So I increment CL_CURRENT to 7 and set CL_REVISION to 0. I haven't added functions/classes, so I don't touch CL_AGE. And I haven't broken backwards compatibility, so I leave CL_AGE at 0. This results in libcln.so.7.0.0, which is clearly bogus, since the new version is a drop-in replacement for the old one! So, back to the second item: Maybe I shoudn't have incremented CL_CURRENT. Then, CL_REVISION is still 0. I haven't added functions/classes, so CL_AGE remains at 0, and I haven't broken backwards compatibility. Oops, then all version numbers remain the same. This is bogus, too! The confugure.ac file in GiNaC is slightly less ambiguous: dnl When making releases, do dnl 1. Increment ginac_lt_revision dnl 2. If any interfaces have been added, removed, or changed since the dnl last release, increment ginac_lt_current and set dnl ginac_lt_revision to 0. dnl 3. If any interfaces have been removed since the last release, set dnl ginac_lt_age to 0. Let's see what happens when I apply this to the new CLN release. This is more clear, since it refers to "interfaces" as opposed to "functions/classes". So I end up with REVISION=1, CURRENT=6 (as before), and AGE=0. This looks better and results in libcln.so.6.0.1. But is this correct? AGE is never incremented! Can you suggest better texts for configure.ac, so making new releases becomes painless? I shamefully have to admit that reading the libtool documentation did not really enlighten me. Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

1 1

Positive add and mul, LaTeX printing
by Vladimir V. Kisil 15 Sep '09

15 Sep '09

Dear All, I think it would be nice if GiNaC will learn that a sum or product of two positive expressions is again a positive expression. This will help, for example, to simply formulae like ((1+x)^{1/2})^2, where x is a positive symbol. It would be also a better LaTeX printing of complicated formulae if \mathrm will be used instead of \mbox (the later is not scaled in fractions, for example). I am attaching a patch which makes these two things. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/

2 2