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
