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
Hi, On Tue, 27 Nov 2001, Pearu Peterson wrote:
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?
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. :^) Regards -richy. -- Richard B. Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>
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
participants (2)
-
Pearu Peterson
-
Richard B. Kreckel