Hi Chris! On Tue, 18 May 2004, Chris Dams wrote:
Some time ago I sent a patch to prevent .series() to revert to .expand() internally. This was because in the case that one has polynomial^some_large_integer the expansion will be hopeless. However, I keep running into this kind of problems. To determine the real_ldegree in mul::pseries, still expansion is used with potentially the same problems.
I think there are two possible solutions to this problem. (1) Tell your users (me included) that they should not be substituting polynomials into each others when they should have used power series from the start. (2) Create (or ask me to create) a patch that solves this particular case and hope that there will not be ten other instances where .series() is going to crash a program. (3) Forbid any occurance of .expand() in any method or function that may be called from .series(). Create a new method to determine the leading behaviour of any expression. Let .series() use this and let .series() work by calculating power series of subexpressions and combining these into the power series for the entire expression.
I am in favour of (3). The only reason not to use (3) would be if someone in this mailing list could come up with an example where (3) clearly is horribly inefficient.
What do other people think?
The third suggestion sounds quite attractive. If I am not mistaken it does, however, lead to some circular reasoning. The question is: how would you go ahead implementing a reliable ldegree routine? Consider a deeply nested expression -- maybe a nested unexpanded polynomial is enough. What's the reliable ldegree? You would recursively descent into the expression tree, inspect candidate expressions, collect their coefficients and finally you would have to test this coefficient for zero, right? If it is zero, then start over again with the next degree. Let's leave the problem of testing for zero aside. That would have to be dodged like we do in other places (pivoting, e.g.). However, come to think about it, that procedure sounds a lot like the process of series expansion itself! *If* we had a series expansion routine which could extract term after term, then we could use it for implementing this reliable ldegree function, I assume. But since our series expansion wants us to agree on an order before we can call it, this does not work. A order guess could lead to way too much computation or it could lead to too few terms. Ugh. In the end, I suspect one would have to fundamentally rewrite the whole series expansion such that it can be used like a stream. Are you with me? Or maybe I'm confused? Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>