- GiNaC-list - ginac.de

cln::notreached_exception
by Dario Pellegrini 05 Jan '21

05 Jan '21

I am on v1.8.0, I have no experience with older versions. This trivial program results in a cln::notreached_exception being thrown. #include <ginac/ginac.h> > int main() { > GiNaC::ex a = GiNaC::Pi; > GiNaC::ex b = 1; > std::cout << GiNaC::ex_to<GiNaC::numeric>(a+b).to_double() << std::endl; > return 0; > } Compiled with: g++ test.cpp -lginac -lcln Here is the full exception message: what(): Internal error: statement in file real/conv/cl_R_to_double.cc, > line 48 has been reached!! > Please send the authors of the program a description how you produced this > error! I would expect that to work, am I wrong?

2 2

cannot compile cpp code that uses GiNaC on Mac OS 10.15.7 (Catalina)
by Di Gi 20 Dec '20

20 Dec '20

Hello, I'm trying to compile cpp code that depends on GiNaC. The code is in this file: https://arxiv.org/src/1912.09099v1/anc/GPLs.cpp and I tried compiling it with the following command: g++ -std=c++11 GPLs.cpp -o GPLs.out -w -lcln -lginac I tried several alternatives for the -std option, but c++11 is the one producing the smallest amount of errors. The output I get is in the attached GPLs.log file. My OS is Mac OS Catalina (10.15.7). My compiler options are as follows: Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1 Apple clang version 12.0.0 (clang-1200.0.32.21) Target: x86_64-apple-darwin19.6.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin I get the very same errors if I use the GNU compiler, but I understand that, under Mac, g++ = gcc = clang. I installed GiNaC through homebrew, and this is the version I have: ginac: stable 1.8.0 (bottled) Not a Computer algebra system https://www.ginac.de/ /usr/local/Cellar/ginac/1.8.0 (66 files, 8.9MB) * Poured from bottle on 2020-12-19 at 16:28:49 From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/ginac.rb License: GPL-2.0 ==> Dependencies Build: pkg-config ✔ Required: cln ✔, python(a)3.9 ✔, readline ✔ I had also tried to install GiNaC as well as CLN from git, but I get similar errors. I inspected GiNaC's lst header (the constructor producing the errors) but I cannot find anything wrong with it. Any help is greatly appreciated. Beste Grüße, Diego

2 3

GiNaC 1.8.0 released
by Richard B. Kreckel 15 Oct '20

15 Oct '20

Hi, GiNaC 1.8.0 has just been tagged. Here are the news: * New routines for the numerical evaluation of iterated integrals like elliptic multiple polylogarithms or iterated integrals of modular forms. * Stronger normalization methods for expressions with powers. Where this is safe, GiNaC now tries replacing various kinds of powers in order to find and cancel common subexpressions. * Improved CMake build. Stay healthy, and happy hacking! -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>

1 0

Release 1.7.11
by Richard B. Kreckel 03 Aug '20

03 Aug '20

Hi, GiNaC 1.7.11 contains some bugfixes. Upgrade, if you can! :-) Take care! -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>

1 0

issue about series involving positive symbol
by Feng Feng 28 Jul '20

28 Jul '20

Hi all, I come across an issue about the series on an expression involving positive symbol, i.e., possymbol in GiNaC. the problem can be reproduced by the following program (test.cpp), for example, we compile the test.cpp to test, and then run the test program several times, we will see different outputs. for example, we can run the bash script in the terminal: for n in {1..20}; do ./test; done PS: if we change the possymbol to symbol in the test.cpp, we will always get correct result. Best regards! Feng --- #include "ginac/ginac.h" using namespace std; using namespace GiNaC; int main() { possymbol t("t"); symbol m("m"), ep("ep"); symtab table; table["ep"] = ep; table["t"] = t; table["m"] = m; parser reader(table); ex in1 = reader("(-3/2*t^2*(2*t*m^2-3*m^2*(-1+t))^(-1)*(-1+t)^(-1))"); ex in2 = reader("((3*pow(m,-2)*pow(-3+t,-1)*pow(-1+t,-1)*pow(t,2))/2)"); cout << "in1-in2 = " << normal(in1-in2) << endl; in1 = pow(in1,-1+ep)*tgamma(ep); in2 = pow(in2,-1+ep)*tgamma(ep); ex diff = series_to_poly(series(in1-in2,ep,1)); lst repl = lst{ep==2,m==1,t==1/ex(3)}; cout << "diff = " << normal(diff.subs(repl)) << endl; return 0; }

3 3

Sqrfree_parfrac Issue GiNaC
by Konstantin Leyde 24 Jul '20

24 Jul '20

Hello, My name is Konstantin Leyde, and I am a master student in physics at the ETH Zurich. For my thesis project, I have been working with the GiNaC library, and I have encountered an issue with the partial fractioning (sqrfree_parfrac) routine: Unless I misunderstood the way the sqrfree_parfrac routine works, it appears that for special cases, the output of the sqrfree_parfrac routine misses a numerical prefactor for one term, and thus returns the wrong answer. Please find attached a pdf, that explains the problem in more detail. In this pdf (as well as separately) we have attached the code that shows the issue. Many thanks in advance, Best wishes, Konstantin

2 1

Release 1.7.10
by Richard B. Kreckel 28 Jun '20

28 Jun '20

Hi, GiNaC 1.7.10 has just been released. The changes are: * Fix collect_common_factors() for hidden zero arguments. * Fix build on modern systems (C++20 and Python3). Take care! -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>

1 0

C binding for GiNaC
by Xianwen Chen (陈贤文) 22 Jun '20

22 Jun '20

Dear all, I wonder if it is possible to use GiNaC in a C program? Is there a binding for that? I guess there may be one, because GiNaC is used in other software, for example, Octave and Sage Math. But I couldn't find relevant information. Yours sincerely, Xianwen

2 2

problem about collect_common_factors
by Feng Feng 22 Jun '20

22 Jun '20

Hi all, I got a strange problem about collect_common_factors, the problem can be reproduced by the following example: ------ symbol a("a"),b("b"),c("c"); symtab table; table["a"] = a; table["b"] = b; table["c"] = c; parser reader(table); ex res = reader("b*((c+c*(1+4*a+2*b+b^2)-c*(1+2*b+b^2)-(1+4*a)*c))-a*(c+c*(1+4*a+2*b+b^2)-c*(1+2*b+b^2)-(1+4*a)*c)"); cout << res << endl; cout << collect_common_factors(res) << endl; ------ the collect_common_factors will throw an error: division by zero. so is this a bug for collect_common_factors? Best regards! Feng

3 2

Issue with derivative of "abs"
by Pierangelo Masarati 16 Jun '20

16 Jun '20

Dear GiNaC users, we have been using GiNaC for years now, to provide our multibody dynamics solver, MBDyn <http://www.mbdyn.org/>, some symbolic differentiation capabilities (perhaps not the most appropriate use, but some users seem to like it). I'll make the story as short as possible. In one of the most interesting applications, the user needs to: - define the variables that represent strains (and strain rates), - the expression for the configuration-dependent generalized forces in short, a constitutive law. The expression's partial derivatives with respect to the strains and strain rates are then automatically computed by GiNaC, and, when needed, the numerical values are substituted and the expressions are evaluated. The related code snippet looks like > GiNaC::symbol gEps("v"); // parameter symbols > GiNaC::ex gExpr; // expressions > GiNaC::ex gExprDEps; // derivatives > > GiNaC::lst l; > > l.append(gEps); > gExpr = GiNaC::ex("v*abs(v)", l); > > gExprDEps = gExpr.diff(gEps); One user recently tried something like this: var = v expr = v*abs(v) # a turbulent viscous law the result was dexpr/dvar = abs(v)+1/2*v*(v+conjugate(v))*abs(v)^(-1) which fails when v = 0 because of the division by zero. I tried with "realsymbol" (since our values can only be real); things, however, didn't change much: dexpr/dvar = v^2*abs(v)^(-1)+abs(v) I realized that the issue is in the derivative of the abs() function; indeed, the proposed formula is rather general (despite failing when numerically evaluated with 0 as the argument). When the argument is real, a more robust representation would be "d(abs(v))/dv = sign(v)". In the case at hand, "d(v*abs(v))/dv = 2*abs(v)" or, as a second choice, "d(v*abs(v))/dv = abs(v) + v*sign(v)". First, I considered the possibility to implement the "sign()" function in GiNaC, but I am not familiar enough with its internals. If it makes sense, I would definitely recommend its introduction. However, I noticed that the "step()" function is implemented (and step(0) correctly evaluates to 1/2); the "sign()" function can then be obtained as "sign(x) = 2*step(x) - 1" when "x" is real. To this end, I modified GiNaC's code as reported here: > diff --git a/ginac/inifcns.cpp b/ginac/inifcns.cpp > index d68afbb5..ec74a435 100644 > --- a/ginac/inifcns.cpp > +++ b/ginac/inifcns.cpp > @@ -321,6 +321,8 @@ static ex abs_expand(const ex & arg, unsigned options) > static ex abs_expl_derivative(const ex & arg, const symbol & s) > { > ex diff_arg = arg.diff(s); > + if (arg.info(info_flags::real)) > + return diff_arg*(2*step(arg) - 1); > return > (diff_arg*arg.conjugate()+arg*diff_arg.conjugate())/2/abs(arg); > } which indeed gives the expected result: dexpr/dvar = v*(-1+2*step(v))+abs(v) I wonder whether my fix can be considered correct and, in case, whether it could be included in the distribution. Sincerely, p. -- Pierangelo Masarati Professore Ordinario di Costruzioni e Strutture Aerospaziali Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

2 1