- GiNaC-list - ginac.de

Memory leak in dynallocate for relational
by Thomas Luthe 09 Jan '17

09 Jan '17

Hi, valgrind reports a memory leak caused by dynallocate<GiNaC::relational, const GiNaC::ex&, const GiNaC::ex&, GiNaC::relational::operators> (basic.h:336). I have attached a minimal example as well as the corresponding valgrind output I get. The executable was produced with g++ 5.4 -O0 and GiNaC 1.7.1. Repeated use of operators == or != for GiNaC::ex does indeed lead to a noticeable increase of memory usage in applications, whereas ex::is_equal does not have the same effect. Cheers, Thomas

2 1

Simplification in GiNaC
by abpetrov 07 Jan '17

07 Jan '17

Hello, I recently wrote a simple program to learn some calculations with GiNaC. This works, But I got some expression which automatically don't become simple. The question is: What is the simplest way to get the expected answer - Ax here? Best regards Petrov A.B. -------------------------------------------------------------------- Output for program: Starting: ./test2 sqrt(m*x^2*A)*sqrt(m^(-1)*A) *** Exited normally *** ------------------------------------------------------------------ Program: #include <iostream> using namespace std; #include<ginac/ginac.h> using namespace GiNaC; void calc_example(){ realsymbol A("A"),m("m"),x("x"); ex e = sqrt(A*m*pow(x,2))*sqrt(A/m); cout << e << endl; } int main(int argc, char** argv) { calc_example(); return 0; }

2 2

Various syntax errors while compiling appln. with Ginac1.7.1
by harish sukhwani 21 Oct '16

21 Oct '16

Hi Everyone, I am new to GiNaC. In our research group. we have a tool written predominantly in C (and some c++ with GiNaC). I have inherited this recently, and I am trying to cross-compile using mingw32 on Ubuntu 14.04 with Win32 target. Note that the compiling application for local target with Ginac1.5 installed works fine. I compile the only single file using GiNaC using i686-w64-mingw32-g++ -c -o symbolic-diff.o symbolic-diff.cpp I see the following error (and a LOT more errors: In file included from /usr/i686-w64-mingw32/include/ginac/basic.h:27:0, from /usr/i686-w64-mingw32/include/ginac/ginac.h:28, from symbolic-diff.cpp:17: (line corresponding to #include <ginac/ginac.h>) /usr/i686-w64-mingw32/include/ginac/ptr.h:37:13: error: expected ';' at end of member declaration refcounted() noexcept : refcount(0) {} ^ /usr/i686-w64-mingw32/include/ginac/ptr.h:37:15: error: 'noexcept' does not name a type refcounted() noexcept : refcount(0) {} I am not sure where to start. ..... FYI, here are my installation steps for CLN1.3.3 and GiNaC 1.7.1 HOST=i686-w64-mingw32 CXX=${HOST}-g++ CC=${HOST}-gcc CPPFLAGS=-I/usr/i686-w64-mingw32/include CXXFLAGS="$CPPFLAGS -O3" CFLAGS=$CXXFLAGS LDFLAGS=-L/usr/i686-w64-mingw32/lib PREFIX=/usr/i686-w64-mingw32 export CC CXX CPPFLAGS CXXFLAGS CFLAGS LDFLAGS HOST ** For CLN ** ./configure --host=$HOST --enable-shared --prefix=$PREFIX && make && make install CLN_CFLAGS=$CPPFLAGS CLN_LIBS="$LDFLAGS -lcln" export CLN_CFLAGS CLN_LIBS ** For GiNaC** ./configure --host=$HOST --enable-shared --prefix=$PREFIX && make && make install Thanks Harish

2 1

Patch: Replace mktemp with mkstemp
by Till Hofmann 08 Oct '16

08 Oct '16

Hi all, while building 1.7.1 I noticed that mktemp is still used. I've attached a patch that replaces mktemp with mkstemp. Note that the behavior is slightly different: The file is opened twice because mkstemp directly opens the file, too. I'm not aware of any other solution to safely create an ofstream for a tmp file. If there is, please let me know. Kind regards, Till

2 1

removed function in 1.7.1 without soname bump
by Till Hofmann 06 Oct '16

06 Oct '16

Hi all, I'm a Fedora co-maintainer for ginac. We're currently working on updating ginac to the new release 1.7.1. During this process, we realized that there is a function that was removed in 1.7.1, but the soname was not changed. Was this intentional? Usually, removing functions requires an soname bump so other software doesn't accidentally link against the wrong version. The removed function is 'method virtual GiNaC::ex GiNaC::pointer_to_map_function_1arg<const GiNaC::ex&>::operator()(const GiNaC::ex&)' I've attached the output of abidiff to this email. For reference, here is the exact command to get the abidiff: $ abidiff --d1 ginac-old/usr/lib/debug/ --d2 ginac-new/usr/lib/debug ginac-old/usr/lib64/libginac.so.6.0.0 ginac-new/usr/lib64/libginac.so.6.0.1 Kind regards, Till

2 3

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