- GiNaC-list - ginac.de

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

Re: [GiNaC-list] [patch] Add solve_algo::markowitz for large sparse systems
by Vitaly Magerya 08 Jun '18

08 Jun '18

On 05/31/2018 05:55 PM, Richard B. Kreckel wrote: > Thanks a lot for your contribution! After doing some (probably too > simplistic) checks with your implementation of Markowitz-ordered > Gaussian elimination and finding no issues I've committed it. > > Regarding style, I've taken the liberty to adjust indentation a little > bit to comply with <https://www.cebix.net/indentation.html>. Thanks; I tried to mimic the style of the rest of the code, but it turned out to be challenging. Is there a set of vim options that implement this style? > Also, > please let's keep the continue statements in conditionals on a line of > their own. This improves debuggability. Apart from that, it's perfect. Sure.

1 0

ldegree changes after expand
by Matthias Naaf 04 Jun '18

04 Jun '18

Dear All, I've just hit an unexpected behavior of the ex.ldegree() method in my application. The problem is that ldegree() gives 0 before and 1 (the expected value) after calling expand() on the expression. I did not expect this, as the tutorial says that degree() and ldegree() "work reliably on non-expanded input polynomials". A small running example and its output are attached. The expression is the one I encountered in my application. This looks like a bug to me, or is it necessary to call expand() before using ldegree()? A related question: What about coeff(), should I call expand() before using coeff()? GiNaC version: 1.7.4 g++ version: 7.3.1 openSUSE (tumbleweed) Thanks in advance for any help on these questions Matthias

2 2