- GiNaC-list - ginac.de

previous release archive
by Eric Deveaud 22 Feb '18

22 Feb '18

Hello, we've setup few days ago some tools using ginac-1.73 as I have to reproduce this using the same version, I would like to know if you provide release archive for old versions or should I go grabbing the git snapshot tag for the release 1.7.3 regards Eric

2 1

Re: [GiNaC-list] Problem of installing ginac on mac os
by Goutam Das 02 Feb '18

02 Feb '18

@Vladimir, thanks but I do not prefer to install Homebrew or MacPorts as most of the time they affects due to broken packages and also much bulky. So I install whatever needed for my work from the source itself. In this case I have installed cln successfully but failed in installing Ginac. @Isuru, after configure, in the Makefile I can see the following: CPPFLAGS = /Users/gkdgoutam/Softwares/HEP_Softwares/Install/Cln134/include: CXXFLAGS = -g -O2

1 3

Release 1.7.3
by Richard B. Kreckel 01 Feb '18

01 Feb '18

Hi, A new GiNaC version has just been released. These are the changes: * Speed up some corner cases of polynomial factorization. * Speed up some corner cases of gcd computation. * Speed up factorization of pre-factored polynomials. * Make matrix::solve() work with hidden (non-normal) zeros. * Fix bug in evaluation of real and imaginary parts of powers. * Fix some LaTeX output, add new function symbol::get_TeX_name(). The following people have contributed patches to this release: - Vladimir V. Kisil - Richard B. Kreckel - Vitaly Magerya Happy hacking! -richy.

1 0

matrix::solve()-related problems
by Vitaly Magerya 01 Feb '18

01 Feb '18

Hi, folks. I've run into a number of problems with matrix solution routines in GiNaC, and I'd like to sort them out one by one. The basic overview of the problems is this: 1) matrix::gauss_elimination checks for zero entries via a simple .is_zero() call without a .normal() call before, so it misses zeros in non-normal form. For example it will not detect that this expression: 1/(x - 1) + 1/(x + 1) - 2*x/(x*x - 1) ... is zero. This leads to "division by zero" errors. Test case: #include <ginac/ginac.h> using namespace GiNaC; int main() { symbol x("x"); matrix mx { {1,0,0}, {0,1/(x+1)-1/(x-1)+2/(x*x-1),1}, {0,1,2}, }; matrix zero(mx.rows(), 1); matrix tmp(mx.cols(), 1); for (unsigned i = 0; i < tmp.nops(); i++) { tmp.let_op(i) = symbol(); } mx.solve(tmp, zero, solve_algo::gauss); return 0; } 2) matrix matrix::solve does the same erorr, so if gauss_elimination returned a matrix with un-normal zeros, it too may error out with "division by zero". Test case: #include <ginac/ginac.h> using namespace GiNaC; int main() { symbol x("x"); matrix mx { {1,0,0}, {0,1/(x+1)-1/(x-1)+2/(x*x-1),1}, {0,0,0}, }; matrix zero(mx.rows(), 1); matrix tmp(mx.cols(), 1); for (unsigned i = 0; i < tmp.nops(); i++) { tmp.let_op(i) = symbol(); } mx.solve(tmp, zero, solve_algo::gauss); return 0; } 3) The default echelon form algorithm, Bareiss elimination, (matrix::fraction_free_elimination) is unbearably slow for sparse matrices, and should never be used with them. This is because of explosive common factor growth during its evaluation. For an illustration, using matrix::fraction_free_elimination on a matrix like this: {{a11,a12,a13,a14}, { 0,a22,a23,a24}, { 0, 0,a33,a34}, { 0, 0, 0,a44}} ... will give you a result like this: {{a11, a12, a13, a14}, { 0,a11*a22, a11*a23, a11*a24}, { 0, 0,a11*a22*a33, a11*a22*a34}, { 0, 0, 0,a11*a22*a33*a44}} Now imagine a similar 100x100 matrix with slightly more complex diagonal elements. Now, there are multiple ways of dealing with these problems. The practical workaround for the moment is to: a) use solve_algo::gauss for all sparse-ish matrices b) normal()ize the whole matrix before passing it into solve() There are places where this workaround is not available. One of such places is matrix::inverse(): it doesn't provide an 'algo' argument, and always defaults to solve_algo::automatic (which means fraction_free_elimination). So for the start I propose to add that argument (see the attached patch). The reservation I have with this patch is other functions (solve() and determinant()) have their own enumerations for the 'algo' argument, while inverse() will be reusing the one from solve(). Not the cleanest thing in the world from API usage point of view. What do you think of it?

4 17

Problem of installing ginac on mac os
by Goutam Das 29 Jan '18

29 Jan '18

I am trying to install ginac on mac os 10.13.2. The Cln1.3.4 is installed without error. I have tried to installed both way: 1. ./configure works with showing === The following minor problems have been detected by configure. === Please check the messages below before running "make". === (see the section 'Common Problems' in the INSTALL file) == ginsh will not compile, because readline headers could not be found. == Documentation may not build, because fig2dev/texinfo is missing. == Reference manual will not build, because doxygen is missing. Configuration of GiNaC 1.7.2 done. Now type "make". These above warning I am ignoring. Next, while doing make I am getting the following error: Making all in ginac /Applications/Xcode.app/Contents/Developer/usr/bin/make all-am /bin/sh ../libtool --tag=CXX --mode=compile g++ -std=gnu++11 -DHAVE_CONFIG_H -I. -I../config -DLIBEXECDIR='"/usr/local/libexec/"' /Users/gkdgoutam/Softwares/HEP_Softwares/Install/Cln134/include/cln: -g -O2 -MT libginac_la-add.lo -MD -MP -MF .deps/libginac_la-add.Tpo -c -o libginac_la-add.lo `test -f 'add.cpp' || echo './'`add.cpp libtool: compile: g++ -std=gnu++11 -DHAVE_CONFIG_H -I. -I../config -DLIBEXECDIR=\"/usr/local/libexec/\" /Users/gkdgoutam/Softwares/HEP_Softwares/Install/Cln134/include/cln: -g -O2 -MT libginac_la-add.lo -MD -MP -MF .deps/libginac_la-add.Tpo -c add.cpp -fno-common -DPIC -o .libs/libginac_la-add.o clang: *error: *no such file or directory: '/Users/gkdgoutam/Softwares/HEP_Softwares/Install/Cln134/include/cln:' make[2]: *** [libginac_la-add.lo] Error 1 make[1]: *** [all] Error 2 make: *** [all-recursive] Error 1 2. I tried to compile with cmake, however there I am getting the following problem: cmake ../ginac-1.7.2 -- Checking for module 'cln' -- No package 'cln' found -- found CLN [/Users/gkdgoutam/Softwares/HEP_Softwares/Install/Cln134/include/cln/version.h], version 1.3.4 CMake Error at /Applications/CMake.app/Contents/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find CLN (missing: CLN_LIBRARIES) (found suitable version "1.3.4", minimum required is "1.2.2") Call Stack (most recent call first): /Applications/CMake.app/Contents/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:377 (_FPHSA_FAILURE_MESSAGE) cmake/modules/FindCLN.cmake:116 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:30 (find_package) -- Configuring incomplete, errors occurred! See also "/Users/gkdgoutam/Softwares/HEP_Softwares/Source/ginac_build/CMakeFiles/CMakeOutput.log". In both cases, the problem seems to come from cln, but could not able to fix. Is it possible to get some help? I am using : gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/c++/4.2.1 Apple LLVM version 9.0.0 (clang-900.0.39.2) Target: x86_64-apple-darwin17.3.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

3 3

Bug? Segmentation while inverting a matrix
by Patrick Schulz 09 Jan '18

09 Jan '18

Hi, i'm getting a segmentation fault while inverting a matrix (the matrix itself is invertable, i checked with the symbolic package for octave). Can anyone give me some pointers why this is happening? Is the matrix ill-formed in some way or is this a bug? Many thanks in advance! I'm running archlinux (Kernel 4.14.12), my compiler is g++ 7.2.1, the GiNaC version i'm using is 1.7.2. Attached is a sample listing which produces the error (at least on my system). Greetings, Patrick

4 5

factor() hangs on a simple expression, randomly
by Vitaly Magerya 28 Dec '17

28 Dec '17

Hi, folks. I have this problem: $ ginsh ginsh - GiNaC Interactive Shell (GiNaC V1.7.2) __, _______ Copyright (C) 1999-2017 Johannes Gutenberg University Mainz, (__) * | Germany. This is free software with ABSOLUTELY NO WARRANTY. ._) i N a C | You are welcome to redistribute it under certain conditions. <-------------' For details type `warranty;'. Type ?? for a list of help topics. > factor((2*x-l)^2*(-1+6*x-l)*(-1+3*x-l)*(-2+4*x-l)*(1+4*x-l)*(4*x-l)*(2+4*x-l)); At this point ginsh either hangs (80% of cases), or gives the correct result (20% of cases). As you can see the expression is already factored, so a hang is pretty unexpected here. Note that if you'll drop two of the factors from that expression, GiNaC won't hang anymore. Here are the cumulative timings you'll typically see via 'perf top' during this hang: 91.54% libginac.so.6.0.2 [.] GiNaC::(anonymous namespace)::factor_multivariate 81.32% libginac.so.6.0.2 [.] GiNaC::(anonymous namespace)::hensel_multivar 79.67% libginac.so.6.0.2 [.] GiNaC::(anonymous namespace)::multivar_diophant 79.67% libginac.so.6.0.2 [.] GiNaC::(anonymous namespace)::univar_diophant 79.67% libginac.so.6.0.2 [.] GiNaC::(anonymous namespace)::multiterm_eea_lift 72.77% libginac.so.6.0.2 [.] GiNaC::(anonymous namespace)::factor_sqrfree 66.18% libginac.so.6.0.2 [.] GiNaC::(anonymous namespace)::eea_lift 64.28% libginac.so.6.0.2 [.] GiNaC::factor 26.99% libginac.so.6.0.2 [.] GiNaC::(anonymous namespace)::operator* 23.67% ginsh [.] yyparse 23.67% ginsh [.] f_factor 16.91% libginac.so.6.0.2 [.] cln::cl_MI::~cl_MI 15.26% libginac.so.6.0.2 [.] cln::cl_I::~cl_I 13.66% libginac.so.6.0.2 [.] cln::cl_MI::cl_MI 13.55% libginac.so.6.0.2 [.] cln::cl_RA::~cl_RA So, any ideas on the nature of this problem, and how to fix it?

2 9

ginac and openmp
by Tania Robens 04 Dec '17

04 Dec '17

Dear all I am trying to run ginac with openmp and get seg faults... [all in a very naive fashion at the moment]. Is the code supposed to run ad hoc with openmp (compiled accordingly of course)/ are there any pitfalls/ ... ?? Any help is appreciated Thanks Best Tania

4 4

Subreddit for Computer Algebra Systems in General Purpose Languages
by Eduardo Cavazos 02 Nov '17

02 Nov '17

Hey folks! Just wanted to let you know, there's a new subreddit dedicated to computer algebra libraries in general purpose programming languages: https://www.reddit.com/r/gplcas/ Feel free to share GiNaC related news there. :-) Ed

1 0

real_part and imag_part
by Jan Rheinländer 09 Aug '17

09 Aug '17

Hi, what is the logic here (example from ginsh)? > real_part(sqrt(-3)); sqrt(-3) > imag_part(sqrt(-3)); 0 > real_part(sqrt(-1)); 0 > imag_part(sqrt(-1)); 1 Greetings, Jan

3 3