- GiNaC-list - ginac.de

bug in diff
by Mario Prausa 16 Feb '19

16 Feb '19

Hi, I found a bug in the diff function. The attached code produces: a: -1 b: 2 c: 1+0 The derivative with respect to c is not simplified completely. I tested this with both GiNaC 1.7.4 and the git version. Cheers, Mario

2 1

[patch] Fix a failure in matrix::division_free_elimination()
by Vitaly Magerya 12 Oct '18

12 Oct '18

Hi, folks. I've run into another case of matrix::solve() failing. This time it seems like the division-free elimination doesn't handle un-normal zeros properly: currently it only does expand() (instead of normal()) on the results of it's calculations, but then uses matrix::pivot() to find the pivot, and that routine also uses expand().is_zero() for zero testing. This breaks when fractions are present in the initial matrix. Not every time, but at least in one example. Note that this problem also affects matrix::solve() with 'algo' set to solve_algo::automatic, which is how I encountered it. I'm attaching the example added to the tests, and also the fix that makes matrix::division_free_elimination() use normal() in stead of expand(). An alternative would be to use normal() in the matrix::pivot() routine, but I decided against it because: 1) that way the results of the normal() call would be discarded; 2) that could slow down e.g. matrix::gauss_elimination() which also uses matrix::pivot(), but normalizes expressions itself. Of course, using normal() makes division_free_elimination only truly "division-free" if the input matrix didn't have fractions. In other cases, GCDs will be computed.

2 2

Building of GINAC fails at compiling GINSH and linking of CLN
by Oleg Kmechak 20 Sep '18

20 Sep '18

Hello, I am student on Physics Faculty at University of Warsaw and new to GINAC. Currently just trying to build it from git repository. first case: I installed and build up CLN(to default /usr/local dir), then I tried to build GINAC. second case: I installed cln from running command sudo apt install libcln-dev and once again tried to build GINAC. Next everything was as described in INSTALL file from GINAC folder: autoreconf -iv ./configure make -j 4 and at some moment it returned: /usr/include/cln/object.h:212: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' collect2: error: ld returned 1 exit status Makefile:474: recipe for target 'ginsh' failed make[2]: *** [ginsh] Error 1 Also please see full log attached below

2 1

Re: [GiNaC-list] Welcome to the "GiNaC-list" mailing list
by Patrick Schulz 07 Sep '18

07 Sep '18

Hi all! I'm working with polynomials in one variable, where i want to compare coefficients and remove some (simplification). For this, i need to iterate over the individual coefficients, but in order to compare them, i need them to be in a standard form. Since only terms with products and sums are involved, i expand the expressions to remove any nested expressions, e.g. R1 * (C1 + C2) -> R1 * C1 + R1 * C2. This works well, but sometime terms of nth power also exist, which are not expanded: GiNaC::symbol R1("R1"); GiNaC::symbol R2("R2"); GiNaC::symbol C1("C1"); GiNaC::symbol C2("C2"); GiNaC::ex e = (R1 + R2) * (C1 + C2 * (R1 * C1)); std::cout << e << '\n' << e.expand() << '\n'; Here we get a term R1^2 * C1 * C2, which does not comply with my "standard form". In the end, ideally i would like to have only a sum of products, no deeper nesting: R1 * C1 + R1 * R1 * C1 * C2 + R2 * C1 + R1 * R2 * C1 * C2 Is there a way to do this? Maybe some information what i'm trying to acchieve: I solve spice netlists and extract transfer functions in s-space. For the simplification (the removal of individual terms) i want to look at the coefficients of the numerator and the denominator polynoms. This is easy, since i use ex::coeff(). So now i have expressions for each power of s. Then i want to store the individual elements in a vector, which makes up the individual products. These are again stored in another vector making up the sum of the polynoms. This works, kinda, but i have to parse the ginac expression, which does not always behave in a way i can foresee. Also i have a strong feeling that there is a better way to do this, given that ginac has already many functions dealing with polynoms. I'm happy to get some pointers on this topic :) Thank you for your help! Greetings, Patrick

2 2

Bug report
by 杨强 24 Aug '18

24 Aug '18

Dear all, I use GiNaC to perform analytic calculation, but when I try to use .numer() and .denom() methods, I get a wrong result. 1. expr.numer()/expr.denom() is not always equal to the original expression!!! 2. Using .numer_denom() method could always get the correct answer. I attach a simple code source file and logger file to check that problem. The logger file will be different when you run the code on your computer. Yours, Yang

3 3

lsolve() fails with "system is not linear"
by Vitaly Magerya 06 Aug '18

06 Aug '18

Here's what I get with the latest GiNaC release, as well as the latest commit: $ ginsh ginsh - GiNaC Interactive Shell (GiNaC V1.7.3) [...] > lsolve({(1+c)^(-1)*(1+x+x*c)==0},{x}); lsolve: system is not linear The problem is that the linearity of the system is tested in lsolve() by subtracting 'x' times it's coefficient from the equation, and seeing if there are any more 'x' remaining. In this case such subtraction results in '-(1+c)^(-1)-(1+c)^(-1)*c*x- (1+c)^(-1)*x+x', where 'x' is not explicitly canceled, thus the error. One workaround that solves this particular case is using 'numer()' on each equation, like so: diff --git a/ginac/inifcns.cpp b/ginac/inifcns.cpp index db40dba6..b83b2548 100644 --- a/ginac/inifcns.cpp +++ b/ginac/inifcns.cpp @@ -1094,7 +1094,7 @@ ex lsolve(const ex &eqns, const ex &symbols, unsigned options) matrix vars(symbols.nops(),1); for (size_t r=0; r<eqns.nops(); r++) { - const ex eq = eqns.op(r).op(0)-eqns.op(r).op(1); // lhs-rhs==0 + const ex eq = numer(eqns.op(r).op(0)-eqns.op(r).op(1)); // lhs-rhs==0 const exset syms = symbolset(eq); ex linpart = eq; for (size_t c=0; c<symbols.nops(); c++) { ... this doesn't look performant to me though, and doesn't obviously solve the general case. Any alternative ideas?

1 0

Debugging with GiNaC
by Patrick Schulz 05 Aug '18

05 Aug '18

Hi all, I'm trying to debug with GiNaC objects. I am aware of the dbgprint() function, however, this function can't be found for a numeric or a symbol. GiNaC::basic has this function, but it can't be found for numeric or symbol. The strange thing also is that gdb can't find any function listed in the class reference of, say, numeric. So the basic question is: How can i print the contents of GiNaC::numeric and GiNaC::symbol while debugging? Thank you very much, kind regards, Patrick

3 2

Using polynomial power series for solving PDEs
by Foad Sojoodi Farimani 03 Aug '18

03 Aug '18

Hello guys again, I'm not sure if you have received my former email but I'm gonna reply to that so you can read it as well: While ago I was trying to use polynomial power series to solve a system of partial differential and algebraic equations, when realized there is no implementation of the idea. There is only Mathematica's AsymptoticDSolveValue which is just for ODEs. So I decided to implement it myself. Thanks to the Sympy community we now have some progress. I have one implementation over here <http://nbviewer.jupyter.org/gist/celliern/b38158d04d9dc3d8079dc44e3b747ac8> by Nicolas CELLIER <https://github.com/celliern> and some ideas over here <https://cs.stackexchange.com/questions/95886/algorithm-for-using-power-seri…> by me and some of SymPy developers. I was wondering if we could join forces to come of with a general algorithm, then implementionation on diffrent languages shouldn't be that difficult. I was wondering if you could take a look at this question <https://cs.stackexchange.com/questions/95886/algorithm-for-using-power-seri…> and help us out. FYI I have made a issue on SymPy's github over here <https://github.com/sympy/sympy/issues/15015#> which you can follow. Best, Foad On Thu, Aug 2, 2018 at 9:40 AM Foad Sojoodi Farimani <f.s.farimani(a)gmail.com> wrote: > Hello everyone, > > I want to generate a multivariate polynomial given an array of nonnegative > integers D=[d1,...,dm]. I want to replicate what I have been suggested > in SymPy, in GiNaC, to see if I can get a better performance. (see here > <https://groups.google.com/forum/#!topic/sympy/V4KRzA-3doI>, here > <https://gist.github.com/Foadsf/07d4649f94f4d71876612a0ec6d9939b>and here > <https://stackoverflow.com/questions/51628270/how-to-generate-a-symbolic-mul…>) > I would appreciate if you could help me with this. > > Best, > Foad >

1 0

[patch] Improve automatic algorithm selection in matrix::solve()
by Vitaly Magerya 18 Jun '18

18 Jun '18

Hi, folks. Since we've recently added solve_algo::markowitz, I thought it would be a good idea to update the automatic elimination algorithm selection logic we have for matrix::solve() (currently living in matrix::echelon_form()). To this end I've constructed a benchmark that generates random-ish matrices and measures how fast matrix::solve() can solve them. The matrix generation works by starting with a known simple solution and then permuting and mixing rows and columns randomly. You can find the code for this procedure at [1]. With that code I've generated a bunch of data points and run a quick analysis on it. Overall, the fastest (on average) algorithm seems to be: For numeric matrices: If ncells > 200 && density < 0.5: Markowitz Otherwise: Gauss For symbolic matrices: If density > 0.6 && ncells <= 12: Divfree If density > 0.6 && ncells < 120: Bareiss Otherwise: Markowitz You can find the details (and some pretty charts) at [2]. The attached patch implements this recommendation. Note that matrix::determinant() also has a similar automatic algorithm selection logic, but I didn't touch it for now. [1] https://github.com/magv/ginac-matrix-solve-bench/blob/master/mx-solve-bench… [2] https://github.com/magv/ginac-matrix-solve-bench/blob/master/analysis.ipynb

2 2

[patch] Add 'algo' parameter to matrix::rank()
by Vitaly Magerya 12 Jun '18

12 Jun '18

Hi, folks. Currently matrix::rank() is hardcoded to use Bareiss elimination, which for some matrices is way too slow (and I had to work around this limitation in my own code). I propose adding an argument that will allow users to select which elimination scheme to use. The argument is the same as matrix::solve() takes (so, solve_algo::*). I've tried to mimic how a similar argument was added to matrix::inverse() by keeping the current set of rank() functions and defining separate ones with the 'algo' argument, with the old ones calling the new ones with solve_algo::automatic. This is instead of using default argument values. I've also put the code that makes the automatic selection of the elimination method into a separate function so that both matrix::solve() and matrix::rank() could share it. There's a bit of similar code in matrix::determinant(), but since the self of determinant algorithms is different from the elimination algorithms, it's not clear if these two could be unified.

2 2