- GiNaC-devel - ginac.de

[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

[PATCH] Fix get_builtin_reader() and make it a bit simpler.
by Alexei Sheplyakov 10 Aug '09

10 Aug '09

The code below seems to be too incorrect or at least too fragile enum { log, exp, // skipped NFUNCTIONS }; std::vector<function_options>::const_iterator it = registered_functions_hack::get_registered_functions().begin(); unsigned serial = 0; for ( ; serial<NFUNCTIONS; ++it, ++serial ) { prototype proto = make_pair(it->get_name(), it->get_nparams()); reader[proto] = encode_serial_as_reader_func(serial); } What happens if a user-defined function(s) get registered *before* "official" ones (so serials of built-in functions won't start from 0)? This can easily happen because the order of initialization in different compilation units is implementation defined. Or someone adds a built-in function and inserts REGISTER_FUNCTION_*P between REGISTER_FUNCTION_1P(log, ...) and REGISTER_FUNCTION_1P(exp, ...)? Or compiler decides to swap REGISTER_FUNCTION_1P(log, ...) and REGISTER_FUNCTION_1P(exp, ...)? The fix is simple: don't fiddle with serials, use the old (pre 1.5.2) approach, that is, let autogen produce the `reader functions' and use them to make a prototype_table. --- ginac/parser/builtin_fcns.def | 84 ++++++++++++++++++++++++++++++++++++++- ginac/parser/default_reader.tpl | 56 ++++---------------------- 2 files changed, 92 insertions(+), 48 deletions(-) diff --git a/ginac/parser/builtin_fcns.def b/ginac/parser/builtin_fcns.def index 96cd0a2..a7379d0 100644 --- a/ginac/parser/builtin_fcns.def +++ b/ginac/parser/builtin_fcns.def @@ -1,14 +1,96 @@ Autogen definitions ginacfcns; +function = { name = "log"; }; +function = { name = "exp"; }; +function = { name = "sin"; }; +function = { name = "cos"; }; +function = { name = "tan"; }; +function = { name = "asin"; }; +function = { name = "acos"; }; +function = { name = "atan"; }; + +function = { name = "sinh"; }; +function = { name = "cosh"; }; +function = { name = "tanh"; }; +function = { name = "asinh"; }; +function = { name = "acosh"; }; +function = { name = "atanh"; }; + +function = { + name = "atan2"; + args = 2; +}; + +function = { + name = "Li2"; + comment = "Dilogarithm"; +}; + +function = { + name = "Li3"; + comment = "Trilogarithm"; +}; + +function = { + name = "zetaderiv"; + comment = "Derivatives of Riemann's Zeta-function"; + args = 2; +}; + +function = { + name = "Li"; + args = 2; + comment = "Polylogarithm and multiple polylogarithm"; +}; + +function = { + name = "S"; + args = 3; + comment = "Nielsen's generalized polylogarithm"; +}; + +function = { + name = "H"; + args = 2; + comment = "Harmonic polylogarithm"; +}; + +function = { name = "lgamma"; }; +function = { name = "tgamma"; }; + +function = { + name = "beta"; + args = 2; + comment = "Beta-function"; +}; + +function = { name = "factorial"; }; + +function = { + name = "binomial"; + args = 2; +}; + +function = { + name = "Order"; + comment = "Order term function (for truncated power series)"; +}; + /* Thease are not functions, but anyway ... */ -function = { name = "sqrt"; }; +function = { + name = "sqrt"; + quasi = 1; +}; function = { name = "pow"; args = 2; + quasi = 1; }; function = { name = "power"; args = 2; + quasi = 1; }; + diff --git a/ginac/parser/default_reader.tpl b/ginac/parser/default_reader.tpl index e65802a..32f20f4 100644 --- a/ginac/parser/default_reader.tpl +++ b/ginac/parser/default_reader.tpl @@ -62,10 +62,10 @@ const prototype_table& get_default_reader() static bool initialized = false; static prototype_table reader; if (!initialized) { - [+ FOR function +] + [+ FOR function +][+ IF (exist? "quasi") +] reader[make_pair("[+ (get "name") +]", [+ (if (exist? "args") (get "args") "1") - +])] = [+ (get "name") +]_reader;[+ + +])] = [+ (get "name") +]_reader;[+ ENDIF +][+ ENDFOR +] std::vector<function_options>::const_iterator it = registered_functions_hack::get_registered_functions().begin(); @@ -87,51 +87,13 @@ const prototype_table& get_builtin_reader() using std::make_pair; static bool initialized = false; static prototype_table reader; - if (!initialized) { - [+ FOR function +] - reader[make_pair("[+ (get "name") +]", [+ - (if (exist? "args") (get "args") "1") - +])] = [+ (get "name") +]_reader;[+ - ENDFOR +] - enum { - log, - exp, - sin, - cos, - tan, - asin, - acos, - atan, - sinh, - cosh, - tanh, - asinh, - acosh, - atanh, - atan2, - Li2, - Li3, - zetaderiv, - Li, - S, - H, - lgamma, - tgamma, - beta, - factorial, - binomial, - Order, - NFUNCTIONS - }; - std::vector<function_options>::const_iterator it = - registered_functions_hack::get_registered_functions().begin(); - unsigned serial = 0; - for ( ; serial<NFUNCTIONS; ++it, ++serial ) { - prototype proto = make_pair(it->get_name(), it->get_nparams()); - reader[proto] = encode_serial_as_reader_func(serial); - } - initialized = true; - } + if (initialized) + return reader; + [+ FOR function +] + reader[make_pair("[+ (get "name") +]", [+ + (if (exist? "args") (get "args") "1") + +])] = [+ (get "name") +]_reader;[+ + ENDFOR +] return reader; } -- 1.6.3.3

1 0

[SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-210-g3f1026f
by git＠ginac.de 10 Aug '09

10 Aug '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 3f1026f0540e4e7ab86656389d09c2152269e6cf (commit) via ab8da4fe0687969d124c2c3b3e6ce62a63376a0a (commit) via dd19b7316b6eba5c49b6a4fb3503c504ec6c866a (commit) via 7f4a4ce46d799ba888b118dfdc8945c92a6c6d6f (commit) via 4ddeb4c2a625a069d71b510aab3ae53138670470 (commit) via 99c7ff6b72691f2eff30f94934d65d1ba7136ff9 (commit) via 554722426543a6e1445ead11167107a69fd21af9 (commit) via aa1afbbdb118846cfc266a1d7a8d5188ac214e0e (commit) via 14aeeca161c7cc2d145b0778ac234341068efef1 (commit) from 5252d38313c423465b9bc37b0618cb8de96d0d4e (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 3f1026f0540e4e7ab86656389d09c2152269e6cf Author: Alexei Sheplyakov <varg(a)metalica.kh.ua> Date: Sat Aug 8 13:03:15 2009 +0300 modular_matrix: don't use STL iterators in {mul, sub}_col and friends. Not using STL iterators makes the code simpler and cleaner. Also we don't have to argue whether the standard ([lib.random.access.iterators]) imposes any pre/post-condictions on operator+=. (cherry picked from commit 59ec13895c97ffd74979a0b811a7571f6de56386) commit ab8da4fe0687969d124c2c3b3e6ce62a63376a0a Author: Jens Vollinga <jensv(a)nikhef.nl> Date: Sun Aug 9 23:38:48 2009 +0200 Added get_builtin_reader() that parses only the builtin GiNaC functions and pow, sqrt, and power. commit dd19b7316b6eba5c49b6a4fb3503c504ec6c866a Author: Jens Vollinga <jensv(a)nikhef.nl> Date: Sun Aug 9 23:27:10 2009 +0200 Fixed include of stdint.h (parser.cpp needs the header as well). commit 7f4a4ce46d799ba888b118dfdc8945c92a6c6d6f Author: Alexei Sheplyakov <varg(a)metalica.kh.ua> Date: Sat Aug 8 13:03:48 2009 +0300 shaker_sort, permutation_sign: fix invalid use of STL iterators. According to the standard incrementing end(), and decrementing begin() are ill-defined operations (see [lib.forward.iterators], [lib.bidirectional.iterators]). (cherry picked from commit 694f839947982f5b12b6c629d5bab522c801630d) commit 4ddeb4c2a625a069d71b510aab3ae53138670470 Author: Alexei Sheplyakov <varg(a)metalica.kh.ua> Date: Sat Aug 8 13:07:14 2009 +0300 symmetry::calchash(): be careful to not dereference past-the-end iterator. (cherry picked from commit 526825bcee294cb20e37d8db6d5040ba0f8c428f) commit 99c7ff6b72691f2eff30f94934d65d1ba7136ff9 Author: Alexei Sheplyakov <varg(a)metalica.kh.ua> Date: Sat Aug 8 13:06:36 2009 +0300 check_parameter_G: fix pontential increment of end(). Incrementing past-the-end iterator is not permitted by the standard, see [lib.input.iterators]. (cherry picked from commit 49a44f7d55ec0d6686d3c32c7081a07d10c93274) commit 554722426543a6e1445ead11167107a69fd21af9 Author: Alexei Sheplyakov <varg(a)metalica.kh.ua> Date: Sat Aug 8 13:02:47 2009 +0300 G_eval: fix incorrect use of STL iterator. According to [lib.bidirectional.iterators] it's not OK to decrement an iterator pointing to the beginning of the sequence. Fortunately random access iterators provided by (current versions of) gcc/libstdc++ don't have this silly limitation, so the code which works with pointers works with iterators without any changes at all. However, - there's no guarantee that the current behavior won't change in the future - some non-GNU compilers are not that smart (i.e. the program segfaults upon when decrementing beginning-of-the-sequence iterator). (cherry picked from commit dda45abd8a2c408f8b3eb7959a10dfb2468ecc3a) commit aa1afbbdb118846cfc266a1d7a8d5188ac214e0e Author: Alexei Sheplyakov <varg(a)metalica.kh.ua> Date: Sat Aug 8 11:43:12 2009 +0300 Fix the compliation error *for real* ... and restore performance Commit 8bf0597dde55e4c94a2ff39f1d8130902e3d7a9b (titled as 'Fixed the parser such that it can read in user defined classes again.') made the parser a bit slower, especially if the input contains many terms of user-defined type. The reason for that is quite simple: we throw and catch an exception every time we construct an object of user-defined type: // dirty hack to distinguish between serial numbers of functions and real // pointers. GiNaC::function* f = NULL; try { unsigned serial = (unsigned)(unsigned long)(void *)(reader->second); f = new GiNaC::function(serial, args); } catch ( std::runtime_error ) { if ( f ) delete f; ex ret = reader->second(args); return ret; } Fortunately functions are aligned and we can use much more efficient technique to distinguish between serial and pointers to functions. commit 14aeeca161c7cc2d145b0778ac234341068efef1 Author: Alexei Sheplyakov <varg(a)metalica.kh.ua> Date: Fri Aug 7 23:22:18 2009 +0300 Fix the compliation error *for real* ----------------------------------------------------------------------- Summary of changes: ginac/factor.cpp | 60 +++++++++-------------- ginac/inifcns_nstdsums.cpp | 7 ++- ginac/parser/default_reader.tpl | 104 +++++++++++++++++++++++++++++++++------ ginac/parser/parse_context.h | 14 +++++- ginac/parser/parser.cpp | 46 +++++++++++++----- ginac/symmetry.cpp | 3 +- ginac/utils.h | 24 +++++++-- 7 files changed, 183 insertions(+), 75 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

2 1

[PATCH 5/6] ncmul::eval(): don't write beyond the end of the vector.
by Alexei Sheplyakov 10 Aug '09

10 Aug '09

--- ginac/ncmul.cpp | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/ginac/ncmul.cpp b/ginac/ncmul.cpp index 0c22a81..fff307d 100644 --- a/ginac/ncmul.cpp +++ b/ginac/ncmul.cpp @@ -339,15 +339,15 @@ ex ncmul::eval(int level) const if (assocseq.empty()) return _ex1; // determine return types - unsignedvector rettypes; - rettypes.reserve(assocseq.size()); + unsignedvector rettypes(assocseq.size()); size_t i = 0; size_t count_commutative=0; size_t count_noncommutative=0; size_t count_noncommutative_composite=0; cit = assocseq.begin(); citend = assocseq.end(); while (cit != citend) { - switch (rettypes[i] = cit->return_type()) { + rettypes[i] = cit->return_type(); + switch (rettypes[i]) { case return_types::commutative: count_commutative++; break; -- 1.6.3.3

2 3

[SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-211-g7a2ac48
by git＠ginac.de 10 Aug '09

10 Aug '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 7a2ac48810afb303e1580afb6266876dda3c5da0 (commit) from 3f1026f0540e4e7ab86656389d09c2152269e6cf (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 7a2ac48810afb303e1580afb6266876dda3c5da0 Author: Alexei Sheplyakov <varg(a)metalica.kh.ua> Date: Sat Aug 8 13:03:38 2009 +0300 ncmul::eval(): don't write beyond the end of the vector. ----------------------------------------------------------------------- Summary of changes: ginac/ncmul.cpp | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0