- GiNaC-devel - ginac.de

The specification of sqrfree()
by Roberto Bagnara 09 Jan '02

09 Jan '02

Hi there, we are developing a GiNaC-based recurrence relations solver. During this work we have found that GiNaC's documentation is not very precise about what a "square-free factorization" is. Below you find what we believe is a sensible definition (which also seems to be compatible with the current implementation). Please, check if that is also consistent with the specification of GiNaC (we would like to avoid relying on non-features that may disappear on a subsequent release). A polynomial p(X) in Q[X] is said <EM>square-free</EM> if, whenever two polynomials q(X) and r(X) in Q[X] are such that p(X) = q(X)^2*r(X), q(X) is constant. The sqrfree function computes polynomials p1(X), ..., pk(X) and positive integers e1, ..., ek such that p(X) = p1(X)^e1 * ... * pk(X)^ek and p1(X) * ... * pk(X) is square-free. If you agree with the above definition we are willing to provide Doxygen and TeXinfo patches against the current sources. All the best, the PURRS team -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

2 1

Just finished compiling version 1.0.2?
by Richard B. Kreckel 21 Dec '01

21 Dec '01

Well, here comes the next load to keep your machine busy. Version 1.0.3 contains two bugfixes without compromising binary compatiblilty: * Fixed a bug where quo() would call vector::reserve() with a negative argument (reported by Pearu Peterson). * Fixed several bugs in code generation (reported by Do Hoang Son). We apologize for the inconvenience... -richy. -- Richard B. Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

decomp_rational(pow(x,-2),x) fails with MemoryError
by Pearu Peterson 20 Dec '01

20 Dec '01

Hi! Note that the following program fails to compute decomp_rational(pow(x,-2),x) #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; int main() { symbol x("x"); cout << "r="<<decomp_rational(pow(x,-2),x) << endl; return 0; } while for decomp_rational(pow(x,-1),x) it succeeds. Any ideas why decomp_rational fails in the previous case, in fact, it seems to fail for all n>1 in x**-n. I am using latest GiNaC from CVS on woody debian. Regards, Pearu

2 1

After lifting the "no-bugs" ordinance...
by Richard B. Kreckel 19 Dec '01

19 Dec '01

...a couple of bugs were indeed discovered and fixed wich leeds us to the release of GiNaC-1.0.2, available at the usual places. It does not break compatibility with prior 1.0.n-versions. Enjoy -richy. -- Richard B. Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

Adding python support to GiNaC
by Pearu Peterson 19 Dec '01

19 Dec '01

Hi! I have been working on the python interface to GiNaC. It is quite usable already and I have tested it in many problems. However, it would be great if some python specific changes that I had to do in GiNaC, could be added to GiNaC. These changes include mostly printing expressions. Earlier I used hooks from GiNaC archive features to get desired output for python, but it was _very_ slow compared to the native GiNaC print hooks. So, please find a patch attached that adds two new print_context classes, print_python and print_python_repr, with the corresponding additions to print methods of the basic classes. The patch includes also the following change in the idx::print method for print_latex context: `a.b' becomes `a_{b}' if b is covariant, `a^{b}', otherwise (you can ignore it if you don't like it). This patch is against GiNaC-1.0.1. I can make it also against the latest GiNaC in CVS. Let me know if needed. Thanks, Pearu

2 2

Bug?: (a^b).unit(a) -> SIGSEGV
by Pearu Peterson 17 Dec '01

17 Dec '01

Hi, Notice that (a^b).unit(a) leads to Segmentation fault. I have failed to track down the source of this fault in GiNaC --- I would expect that this expression should throw an exception "invalid expression in unit()", but something gets wrong elsewhere. Any ideas? Pearu For your convinience, here is a sample program: #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; int main() { symbol a("a"),b("b"); ex e = power(a,b); cout << "e="<<e<< endl; cout << "e.unit(a)="<<e.unit(a)<< endl; return 0; }

4 3

How to use sqrt for input expression?
by Hidehiro FUJIO 14 Dec '01

14 Dec '01

Dear GiNaC developers, I'm using GiNaC for making numerical simulation tools. My problem with GiNaC is how to handle 'sqrt' function in expression input. The simplest example is, ======================================= #include <ginac/ginac.h> using namespace GiNaC; #include <iostream.h> int main() { symbol x("x"); ex e("sqrt(x)",lst(x)); cout << e <<endl; } ======================================= When it runs, it makes core dump. When I use 'sin' instead of 'sqrt', the result is what I expected with GiNaC library. Is it a bug or normal? If normal, how to input expression that contains 'sqrt' function? Best regards, Hidehiro Fujio NEC Corporation, Internet System Laboratory Kawasaki, Japan 216-8555 E-mail: fujio(a)ccm.cl.nec.co.jp

2 1

invalid expression in content|unit|...()
by Pearu Peterson 08 Dec '01

08 Dec '01

Hi, While unit-testing pyginac, I found the following inconsistency: 1) define a = symbol("a") b = symbol("b") c = constant("c") 2) observe content(2,a) -> 0 (ok) content(2*a + 4*c,a) -> 2 (ok) content(a*c,a) -> exception 'invalid expression in unit()' ?! content(a*b,a) -> b (ok) 3) similar behaviour can be observed also for other functions like unit,.. The question is: Is it possible to unify the behaviour of the relevant functions? That is, to extend them to accept other objects in addition to symbol, numeric, add, etc. Or, to raise an exception whenever there are alien object in expressions. (Though, constants should not be alien when comparing them with symbols.) My argument to consider this inconsistency as a problem is that this behaviour is confusing and could lead to difficult-to-find bugs. Thanks, Pearu

3 6

Note on pseries::power_const() method.
by Pearu Peterson 28 Nov '01

28 Nov '01

Hi again, pseries::power_const() has second argument int deg that allows negative values of deg. If one calls this method with negative deg then the line co.reserve(deg); will cause MemoryError as (unsigned)deg gets really big. My questions are: 1) Is there any sense using negative deg? If yes, then the above indicates a bug. If no, then an exception should be thrown. 2) In case negative deg is valid, then is there a reason why power_const() method needs this argument (and methods mul_const(),etc don't)? In the interface to python, I have used the following rule to find the default value for deg: If p==pseries(...) and n is integer, then deg in p.power_const(n,deg) is found as follows ldeg = abs(n * p.ldegree(p.get_var())) deg = abs(n * p.degree(p.get_var())) deg = max(ldeg,deg) + 2 With this rule, I have found that equation (p^n)^m == p^(n*m) for all integers m,n (also negative). holds (and therefore seems sensible to me). Do you see any faults in this rule? Thanks, Pearu

2 2

Bug: ex(numeric(0)).series(x==0,2).is_zero() returns incorrectly 0
by Pearu Peterson 27 Nov '01

27 Nov '01

Hi! The explanation for this bug is that pseries defines its own is_zero() method that is not used within ex::is_zero() method. As a possible solution: define basic::is_zero() (with the contents of current ex::is_zero()) and redefine ex::is_zero() to call ex::bp->is_zero(). I guess that matrix class could also have its own is_zero() method. Pearu

1 0