- GiNaC-list - ginac.de

ex thread safe?
by Zhao Li 23 Sep '16

23 Sep '16

We are trying to implement the GiNaC calculation in multi-thread by using functor, auto func = [](void)->void {…}; However we found that (pointer) problem arises if the arguments are passed by reference. auto func = [&](void)->void {…}; But it seems okay to pass by value. auto func = [=](void)->void {…}; We were wondering if it is really okay to pass by value, or we have to transfer GiNaC::ex into string as argument. And we do not understand why passing by reference is not okay. Cheers, Zhao

1 0

Evaluating multiple polylogarithms using GiNaC
by Peter Banks 10 Aug '16

10 Aug '16

Hi there, I am having a bit of trouble evaluating some multiple polylogarithms using the latest version of GiNaC. GiNaC is giving me a different response depending on whether I input the values as fractions or decimals. Specifically, I'm trying to find a floating point representation for Li({1,1,2}, {1+1/2*I, 1, 3/5 - 4/5*I}). I've tried this by running (in ginsh): evalf(Li({1,1,2}, {1+1/2*I, 1, 3/5 - 4/5*I})); but this seems to hang (I've run it for over 12 hours with no result). On the other hand, running evalf(Li({1,1,2}, {1+0.5*I, 1, 3/5 - 4/5*I})); gives an answer almost immediately. I've tried this using a C++ program (see attached) which behaves in the same way: no result using the fraction but an answer with no issues using a decimal number. These calculations have been run using GiNaC 1.7.0 (stable & from git) on ArchLinux. Please let me know if there is anything I should try. Peter PS: I tried sending this email from a different address but it said it was greylist - I apologise if I've sent this twice.

1 0

Bug in GiNaC 1.7.0
by Mario Prausa 20 Jul '16

20 Jul '16

Hi, I found a regression in GiNaC 1.7.0. In basic.cpp (function subs_one_level) the lines 588 auto it = m.find(*this); 589 if (it != m.end()) 590 return it->second; 591 return *this; are causing problems. In GiNaC 1.6.7 we have 599 ex thisex = *this; 600 it = m.find(thisex); 601 if (it != m.end()) 602 return it->second; 603 return thisex; which work properly. The problem with the 1.7.0 version is, that the this-pointer is dynamically allocated in line 618 (when called from line 629). *this is implicitly casted into an ex, both in line 588 and in line 591. As the dynallocated-flag is set, the first cast destroys the this-pointer, and the second cast crashes. Mario

2 2

Bug report: Problem with matrix inversions
by Dorel, Mathurin 09 May '16

09 May '16

Hello, Using GiNaC, I recently encountered problems with the symbolic inversion of matrices, the inversion does not occur (or take more than 2h, which is the time I let the program run). I wrote a minimum code that exhibits the problem (the source code is in the zip file ginac_inversion_error_dorel.zip with a Makefile and my version compiled on Debian GNU/Linux 7.10 (wheezy)). The script simply build an symbolic matrix, with -1 in the diagonal and tries to invert it. Usage: ./ginac_testing < adjacency_list I ran my test script on a Debian GNU/Linux 7.10 (wheezy) machine with 16Gb of RAM and 8 i7-3770 processors, so the computation power and the memory shouldn't be the problem (and I checked, the memory is faaar from being full). The input file represents a directed graph. I joined several representative examples (in examples_ginac.zip): - network_colonet.tab: does not work; - lesscJun_network_colonet.tab: does not work; - MEK-ERK_network_colonet.tab: does the inversion in 45s, it is only 'network_colonet.tab' with one entry removed (but which removal removes a cycle in the graph); - plusdummy_MEK-ERK_network_colonet.tab: does the inversion in 52s, it's the previous network with a link that does not add any cycle; - IKK-ERK_onlyEGF.tab: does the inversion in 830s/1400s !!, it is 'network_colonet.tab' with several entry removed, but with no cycles removed; - onlyEGF.tab: does the inversion in 35~45s, it is the previous network with the IKK->ERK link remove, which removes a cycle; - noTABK_EGF.tab: does the inversion in 43s, it is the 'onlyEGF' with extra-links removed Is this an expected behaviour ? Did I reach some limit of GiNaC on the size or complexity of the expression ? In my real program, I also need to evaluate the expressions in the inverted matrix, which also seems to take some time for the examples that are long to invert. I also tried the inversions in Mathematica, and those matrices are perfectly invertible (you can check by converting the input files to an adjacency matrix with the python script and executing the commands in 'script_mathematica'). I find surprising that it takes so long, given that the matrices are not that big (and quite sparse) Thanks for any help regarding this problem, Mathurin Dorel

1 0

Let's all embrace C++11 with the GiNaC 1.7.0 release
by Richard B. Kreckel 30 Apr '16

30 Apr '16

Hi, A new GiNaC release is out and available. Beginning with this release, GiNaC will not work with pre-C++11 compilers. The configure script will try to set the necessary compiler flags for you. Here's the news summary: * Make use of C++11 features: - Use new language features 'auto', 'nullptr', 'constexpr', range-based for loops, the contextual keyword 'override', static 'noexcept' operator, etc. - Add initializer list ctors for container<>, lst and nested initializer lists ctor for class matrix. - Add many rvalue reference overloads for ctors from std containers. (Note that whether they really speed up things depends on whether evaluation leaves the container unchanged or not.) - Rvalue reference overloads for ctors from std containers made it possible to remove the manual 'discardable' hack and std::auto_ptr<T> for good. - New dynallocate<T>(args...) helper functions obsolete manual allocation on the heap and setting the dynallocated status flag. - Got rid of C++98ish algorithm features (bind2nd, etc.) and replaced them with lambdas. * Make add::eval(), mul::eval() more careful so they return an evaluated, canonical expression without compromise. * Remove 'level' argument of all .eval() methods. This has become possible by ensuring that add::eval() and mul::eval() evaluate their own structure without compromise (this was not guaranteed before). If all ex are evaluated, any object which is an aggregate of such ex will only ever have to evaluate itself, obsoleting the need for recursing. * Remove 'level' arguments of all .evalf() and .normal() methods. They were modeled after the .eval() methods. * Make relational::rhs() and lhs() nonvirtual. * Add support for power::info(info_flags::real). * Add fderivative::derivatives() method. * Remove broken info_flags::algebraic. * Remove unmaintained support for Cint. * Remove unfinished andcode for hash table-based expairseq. * Remove deprecated ex::to_rational(lst) and ex::to_polynomial(lst). * ginac-excompiler installs in $LIBEXECDIR now, not in $BINDIR. * Many minor performance enhancements. Happy hacking -richy. PS: And to those on ginac-devel I apologize for my git tag abuse. -- Richard B. Kreckel <http://in.terlu.de/~kreckel/>

1 0

Given a formal iterated derivative (GiNaC::fderivative), what actually is it?
by Ricardo Buring 14 Apr '16

14 Apr '16

Dear list, Using GiNaC one can define a symbolic/formal function f of two variables as follows: DECLARE_FUNCTION_2P(f) REGISTER_FUNCTION(f, dummy()) Formal derivatives can be computed by defining symbols x, y and calculating e.g. f(x,y).diff(x, 3).diff(y, 2) which is printed as D[0,0,0,1,1](f)(x,y) This is fantastic. Now, I would like to obtain the list [0, 0, 0, 1, 1] from the above expression. Checking the printing code GiNaC::fderivative::do_print, this is stored in a GiNaC::paramset. However, it's protected, and it doesn't seem to be accessible by any method. My attempt if (is_a<fderivative>(e)) { fderivative fder = ex_to<fderivative>(e); for (auto x : fder.parameter_set) cout << x << ", "; } therefore fails. Could an accessor or some such be implemented so this (basic) operation becomes possible? Best regards, Ricardo

3 13

Release 1.6.7
by Richard B. Kreckel 29 Feb '16

29 Feb '16

Hi, A new GiNaC release is out and available. It fixes two elusive bugs in sqrfree() and normal(), which indirectly also affect numer() and denom(). Happy hacking -richy. -- Richard B. Kreckel <http://in.terlu.de/~kreckel/>

1 0

Re: [GiNaC-list] erf()
by Vladimir V. Kisil 26 Feb '16

26 Feb '16

>> Vincent Huber vincent.huber at cemosis.fr VH> Is there a *Ginac* way to compute the erf() function ? At present, I do not see any other ways but: 1. Use some external library (GSL?) to evaluate numerical values of the function. 2. Write user-defined function if any symbolic properties are required. -- 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

erf()
by Vincent Huber 24 Feb '16

24 Feb '16

Dear members, Is there a *Ginac* way to compute the erf() function ? All the best, VH -- Docteur Ingénieur de recherche CeMoSiS <http://www.cemosis.fr> - vincent.huber(a)cemosis.fr Tel: +33 (0)3 68 8*5 02 06* IRMA - 7, rue René Descartes 67 000 Strasbourg

1 0

Possible bug in sqrfree
by Diego Conti 03 Feb '16

03 Feb '16

Hi, if I understand correctly, the preconditions of sqrfree do not require the operand to be in expanded form. However, invoking it on some non-expanded polynomials results in a division-by-zero error on my system (code attached). Is this a bug in sqrfree? I am using gcc 5.1.1 and GiNaC 1.6.6. Diego

2 1