Note on pseries::power_const() method.

[Pearu Peterson]

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