From: Rainer Schöpf <rainer.schoepf@gm...>  20110912 17:07:35

While testing some new code for the main tree, I came upon an odesolve example that no longer works, (ex. 7 from zimmer.tst): In PSL, the whole system crashes with a SIGSEGV. Even after fixing the particular bug causing the crash, the example takes a very long time until memory is exhausted. The reason behind this behaviour is the attempt to try substitutions before running the integrator proper. A simple example of this problem is int(e^(1/x)*sqrt(x2),x); 1/x 5 1/x 3 1/x 2 (2*(105*e *sqrt(x  2)*x + 420*e *sqrt(x  2)*x + 280*e *sqrt(x  2)*x 1/x 1/x + 672*e *sqrt(x  2)*x + 160*e *sqrt(x  2) 1/x 1/x e 4 e 4  320*int(,x)*x  2464*int(,x)*x 6 5 sqrt(x  2)*x sqrt(x  2)*x 1/x e 4 4  3360*int(,x)*x ))/(315*x ) 4 sqrt(x  2)*x Or try this: on combinelogs; int(e^(1/x)*sqrt(x2),x); This result is silly; replacing the original integral by as um of more complicated ones. Running with "on trint;" shows that the substitution code tries all kind of substitutions to simplify the integral, but never comes back to the original integrand when the substitution doesn't give a better result. I'm well aware of the fact that "a better result" is a vague concept and unlikely to be accessible algorithmically. However, the current code can easily iterate until resources are exhausted; try this for a example: on combinelogs; int(e^(1/x)*sqrt(x2)/sqrt(x),x); or int(e^(1/x^3)*sqrt(x2)/sqrt(x),x); I propose to check that a substitution doesn't introduce a new transcendental kernel. Take the last two integrals: In both cases, the substitutions applied are 1. x = y^2+2 2. y = sqrt(2)*sinh(z) which lead to new kernels exp(1/(2*cosh(z)^2)) and exp(1/(8*cosh(z)^6)), respectively. The occurence of these should prevent the substituted integral to be tried. Comments are welcome. Rainer 