- GiNaC-devel - ginac.de

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-618-g3ea59519
by Richard B. Kreckel 16 Feb '19

16 Feb '19

1 0

bug fix for inifcns_nstdsums.cpp
by Stefan Weinzierl 12 Dec '18

12 Dec '18

Dear all, attached is a small patch, which fixes a bug in G_do_hoelder related to the fact that in CLN a complex number of type cl_N with vanishing imaginary part is not necessarily a real number of type cl_R. The bug is a variant of the issues discussed in https://www.ginac.de/pipermail/ginac-devel/2014-January/002077.html The bug has been reported by T. Huber. Best wishes, Stefan

2 1

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-616-g39eceef4
by Richard B. Kreckel 12 Dec '18

12 Dec '18

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 39eceef41403ae77569110626f1fc957243228b7 (commit) from 96be7a17790700998e2d071e00ad5c1ffb4a2d3e (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 39eceef41403ae77569110626f1fc957243228b7 Author: Stefan Weinzierl <weinzierl(a)uni-mainz.de> Date: Wed Dec 12 22:53:12 2018 +0100 G_do_hoelder: fix case with real x values which are not of type cl_R. In CLN, a complex number of type cl_N with vanishing imaginary part is not necessarily a real number of type cl_R. This bug has been reported by T. Huber. ----------------------------------------------------------------------- Summary of changes: ginac/inifcns_nstdsums.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Faster unarchiving of large equation systems
by Kemlath Orcslayer 12 Dec '18

12 Dec '18

Dear All, I’m using GiNaC for automatic derivation of the Jacobian for very large non-linear equation systems for use in the Sundials suite of solvers. The need for parallelisation arose and I used MPI for the job since GiNaC is not well suited for multi threading due to its ref counting scheme. So I setup appropriate MPI broadcasting code for GiNaC ex() objects using the available archive classes in GiNaC and boost based memory stream IO. All went well except for the unarchiving performance…. The problem lies in symbol::read_archive where for each unarchived symbol the list of ALL symbols is searched for a symbol of the same name: void symbol::read_archive(const archive_node &n, lst &sym_lst) { …... // If symbol is in sym_lst, return the existing symbol for (auto & s : sym_lst) { if (is_a<symbol>(s) && (ex_to<symbol>(s).name == tmp_name)) { *this = ex_to<symbol>(s); …… For cases with 500K symbols this becomes unbearably slow (and this has to happen on each MPI-node) My solution in my little local GiNaC branch was to introduce a second read_archive interface called read_archive_MPI which instead of a GiNaC::lst &sym_lst gets a std::map<std::string, ginac::ex> map that allows for quickly finding a previously stored symbol of the same name: void symbol::read_archive_MPI(const archive_node &n, SymbolMap &sym_lst) { inherited::read_archive_MPI(n, sym_lst); serial = next_serial++; std::string tmp_name; n.find_string("name", tmp_name); // If symbol is in sym_lst, return the existing symbol SymbolMap::iterator it = sym_lst.find(tmp_name); if(it != sym_lst.end()) { *this = ex_to<symbol>((it->second)); This approach is ABI compatible to older code but requires read_archive_MPI members in all ginac::basic derived objects. I’d like to stress that this does not introduce any MPI dependencies in GiNaC, the MPI serialisation code is separate and merely utilises the new archiving system. None the less I figured I might share this with you since I deem it a reasonable improvement for large equation systems and makes GiNaC available for MPI computing. Let me know what you think Klaus

2 1

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-615-g96be7a17
by Richard B. Kreckel 12 Oct '18

12 Oct '18

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 96be7a17790700998e2d071e00ad5c1ffb4a2d3e (commit) from a039abd06ed205ed9868ff1ceb1378082f8cb1ab (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 96be7a17790700998e2d071e00ad5c1ffb4a2d3e Author: Vitaly Magerya <vmagerya(a)gmail.com> Date: Fri Oct 12 20:45:27 2018 +0200 Handle un-normal zeros properly in the division-free elimination. Call .normal() instead of just .expand(), such that matrix::pivot() finds the pivot. Note that this problem also affects matrix::solve() with 'algo' set to solve_algo::automatic. Of course, using .normal() makes division_free_elimination only truly "division-free" if the input matrix didn't have fractions. In other cases, GCDs will be computed. ----------------------------------------------------------------------- Summary of changes: check/exam_matrices.cpp | 26 ++++++++++++++++++++++++++ ginac/matrix.cpp | 2 +- 2 files changed, 27 insertions(+), 1 deletion(-) 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-614-ga039abd0
by Richard B. Kreckel 04 Oct '18

04 Oct '18

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 a039abd06ed205ed9868ff1ceb1378082f8cb1ab (commit) via 1109fafaa3f5da6d1483744c4bdee6f01a37c5c5 (commit) from 45ca93fc48c14f733de73ffbbfef0834be731b08 (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 a039abd06ed205ed9868ff1ceb1378082f8cb1ab Author: Richard Kreckel <kreckel(a)ginac.de> Date: Thu Oct 4 21:32:21 2018 +0200 Update m4/ax_cxx_compile_stdcxx.m4 to current upstream version. commit 1109fafaa3f5da6d1483744c4bdee6f01a37c5c5 Author: Richard Kreckel <kreckel(a)ginac.de> Date: Thu Oct 4 21:28:42 2018 +0200 [DOC] Explaining in tutorial sign ambiguity for numer() and denom(). Based on a patch provided by Vladimir V. Kisil <kisilv(a)maths.leeds.ac.uk>. ----------------------------------------------------------------------- Summary of changes: doc/tutorial/ginac.texi | 7 +++++-- m4/ax_cxx_compile_stdcxx.m4 | 42 ++++-------------------------------------- 2 files changed, 9 insertions(+), 40 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Re: [GiNaC-devel] [GiNaC-list] Bug report
by Vladimir V. Kisil 24 Aug '18

24 Aug '18

Hi, >>>>> On Thu, 23 Aug 2018 13:22:06 +0800 (GMT+08:00), 杨强 <acrobat(a)mail.ustc.edu.cn> said: > Dear all, I use GiNaC to perform analytic calculation, but when I > try to use .numer() and .denom() methods, I get a wrong result. > 1. expr.numer()/expr.denom() is not always equal to the original > expression!!! 2. Using .numer_denom() method could always get the > correct answer. It is not actually a bug. Since a/b = (-a)/(-b), numer() and denom() are only defined up to a sign. Thus their separate evaluation may lead to expr.numer()/expr.denom() with the opposite sign to expr. I am proposing a patch to tutorial reminding that, Best wishes, Vladimir -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: Geometry of cycles http://moebinv.sourceforge.net/

1 0

CLN and GiNaC patches for Win64 build
by Jan Rheinländer 01 Jul '18

01 Jul '18

Hi, I reviewed Robert's patches and added some of my own, that were necessary for GiNaC to work with CLN on Win64. They can be viewed on Github: === CLN === https://github.com/jrheinlaender/cln/commits/win64 There are two kinds of patches: - Patches required for Win64 platform (e.g. UL is 32 bit type on that platform). Mostly due to Robert (Number 1-10) - Cosmetic patches to avoid unnecessary compiler warnings (e.g. confusion of class and struct) Most patches I surrounded with #ifdef _M_AMD64 so that other platforms will be unaffected === GiNaC === https://github.com/jrheinlaender/ginac/commits/win64 - Here I removed some old patches that are not required any more because of improvements in MSVC 2015 - And added a few constructors from size_t I hope these patches are OK and can be included in master. Am 24.02.2018 um 12:49 schrieb Robert Szalai: > > Here is the previous win64 patch set... > > ---------- Forwarded message ---------- > From: "Robert Szalai" <robicjedi(a)gmail.com <mailto:robicjedi@gmail.com>> > Date: Aug 15, 2012 02:22 > Subject: Re: [CLN-list] MinGW64 build > To: "CLN discussion list" <cln-list(a)ginac.de <mailto:cln-list@ginac.de>> > Cc: > > Hi Alexei, > > I've splitted the path into 10 parts. There is a bigger one that > is only > s/long/intptr_t/ and s/unsigned long/uintptr_t/ > the rest is very small. > > Hopefully this can now be applied. > > > Ditto (the corresponding hunk is not quite optimal, though. > {s,u}int32 > > can be typedef'ed to {,u}int32_t => no need for ugly #if's). > > I was thinking of this, however we need exactly the same > underlying type as > (u)intptr_t for the same sized integer to avoid compiler confusion. > So in some cases (e.g. on i686 Linux) stdint.h might define > int32_t as int and intptr_t as long > and in this case the compiler will complain about multiple > definition of the same function. > > Bests, > Robert > > > > _______________________________________________ > CLN-list mailing list > CLN-list(a)ginac.de > https://www.cebix.net/mailman/listinfo/cln-list

2 4

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-612-g45ca93fc
by git＠ginac.de 20 Jun '18

20 Jun '18

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 45ca93fc48c14f733de73ffbbfef0834be731b08 (commit) from 26840ecc367d9f9dd4e3758233be1bdd3563cd8a (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 45ca93fc48c14f733de73ffbbfef0834be731b08 Author: Vitaly Magerya <vmagerya(a)gmail.com> Date: Wed Jun 20 01:13:07 2018 +0200 Consider solve_algo::markowitz in automatic elimination algorithm selection. Cf. <https://www.ginac.de/pipermail/ginac-list/2018-June/002211.html>. ----------------------------------------------------------------------- Summary of changes: ginac/flags.h | 8 +++++--- ginac/matrix.cpp | 37 +++++++++++++++++++++++++++---------- 2 files changed, 32 insertions(+), 13 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-611-g26840ecc
by git＠ginac.de 13 Jun '18

13 Jun '18

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 26840ecc367d9f9dd4e3758233be1bdd3563cd8a (commit) from 48619ed77871a6bcae23df460f426fc34698cd1e (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 26840ecc367d9f9dd4e3758233be1bdd3563cd8a Author: Vitaly Magerya <vmagerya(a)gmail.com> Date: Wed Jun 13 23:07:45 2018 +0200 Add optional matrix::rank() algorighm selection. Before, matrix::rank() was hardcoded to use Bareiss elimination, which for some matrices is way too slow (and I had to work around this limitation in my own code). I propose adding an argument that will allow users to select which elimination scheme to use. The argument is the same as matrix::solve() takes (so, solve_algo::*). I've tried to mimic how a similar argument was added to matrix::inverse() by keeping the current set of rank() functions and defining separate ones with the 'algo' argument, with the old ones calling the new ones with solve_algo::automatic. This is instead of using default argument values. I've also put the code that makes the automatic selection of the elimination method into a separate function so that both matrix::solve() and matrix::rank() could share it. There's a bit of similar code in matrix::determinant(), but since the self of determinant algorithms is different from the elimination algorithms, it's not clear if these two could be unified. ----------------------------------------------------------------------- Summary of changes: doc/tutorial/ginac.texi | 14 +++---- ginac/matrix.cpp | 108 ++++++++++++++++++++++++++---------------------- ginac/matrix.h | 4 ++ 3 files changed, 69 insertions(+), 57 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0