On Wed, 28 Nov 2001, Richard B. Kreckel wrote:
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?
The rule itself look very interesting. I think I shall play with it when I find time...
...however, why are you calling pseries::power_const() and all this? It should only be called from within power::series() and if you look there you will see that the second argument is just passed along. Err, maybe pseries::power_const shouldn't have been public in the first place. :^)
I used pseries::power_const() to find the result of p ^ n where p is a pseries object. But now I see that I could use power::series() for that (and applying my rule by default). Do you think that it could be a default behaviour for power (and other) operation in GiNaC? Are there reasons to keep arithmetic operations with power series "lazy"? That is, to find out, say, `p+1', one needs to call series(x==x0,order) method explicitly (and therefore this can be a source for bugs if the programmer makes a typo in specifying the right x0)? Nevertheless, it's fine for me if you protect pseries::power_const() method (sofar I have assumed that public methods are public). However, now I find that
p=((x+2)**4).expand().series(x==2,3) (p**2).series(x==2,4) 65536+131072*(-2+x)+114688*(-2+x)**2+Order((-2+x)**3) ((p+1)**2).series(x==2,4) 66049+131584*(-2+x)+114880*(-2+x)**2+49152*(-2+x)**3+Order((-2+x)**4)
which is really odd (though it can easily be a bug in pyginac...). Regards, Pearu