December 2018 - GiNaC-devel

evalf() on cube roots
by Jan Rheinländer 21 Sep '19

21 Sep '19

Picking up this old thread... I would like to submit a patch that allows choosing the convention for negative cube roots between the solution on the principal branch and the real-valued solution. That is, in the cln library, file complex/transcendental/cl_C_expt_C.cc I would like to handle the following case separately: y rational and y ratio m/n x rational and x < 0 n odd What about introducing a flag called (e.g.) cln::cl_odd_roots_of_rationals_real (similar to cln::cl_inhibit_floating_point_underflow)? If the flag is false (default), the above case evaluates to exp(log(x) * y) as before If the flag is true, it evaluates to (-1)^m * (-x)^(m/n) Would such a patch be acceptable? Greetings, Jan Rheinländer Am 02.08.2015 um 21:55 schrieb Richard B. Kreckel: > On 08/02/2015 08:59 PM, Jan Rheinländer wrote: >>> There isn't. GiNaC, like almost all other systems, returns the solution >>> on the principal branch, compatible with exp(log(-1)/3). >> I suppose there is some excellent mathematical reason for this... > Actually, there isn't. Branch cuts are a matter of convention. > Nothing more but also nothing less. > >> but for >> me it means that I can't use GiNaC to verify Cardano's formula for a >> cubic function: >> >>> x = (-1 - sqrt(2))^(1/3) + (-1 + sqrt(2))^(1/3); >> (-1-sqrt(2))^(1/3)+(-1+sqrt(2))^(1/3) >> >>> evalf(x^3 + 3 * x + 2); >> 3.3544445609126528848+8.9073474964875349776*I >> >> Surely there must be a way to verify such a formula in GiNaC??? > It should be straightforward to replace such rational expressions by the > form you want them to be in before calling evalf(), using techniques > such as these: <http://www.ginac.de/FAQ.html#advanced> > > Cheers > -richy.

2 2

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