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
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
+ 672*e *sqrt(x - 2)*x + 160*e *sqrt(x - 2)
e 4 e 4
- 320*int(----------------,x)*x - 2464*int(----------------,x)*x
sqrt(x - 2)*x sqrt(x - 2)*x
e 4 4
- 3360*int(----------------,x)*x ))/(315*x )
sqrt(x - 2)*x
Or try this:
on combinelogs; int(e^(1/x)*sqrt(x-2),x);
This result is silly; replacing the original integral by as um of more
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:
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
respectively. The occurence of these should prevent the substituted integral to be
Comments are welcome.
Get latest updates about Open Source Projects, Conferences and News.