Re: [Reduce-algebra-developers] sometimes reduce process gets killed on its own

[Arthur N. <ac...@ca...>]

The following, run via
    bootstrapreduce badint.red -l badint.log -k40M
seems to show that the sink into insanity arises within a call to 
multoutdenr. This tried to remove roots from the denominator of an 
expression into the numerator by multiplying each by a conjugate of the 
denominator. The mix of various jolly exponents here has - I guess - got 
in in a twist so I finds a conjugate and multiplies only to find there 
are still roots in the denominator. So it tries again and again until 
memory is full and the world collapses.

Now is not the moment for me to know how to fix this, but at least this
is a failure in a short fragment of code that is trying to something
that is understandable.

The only change in this function definition since 1987 has been that if 
after tidying of the denominator is a negative integer then signed of 
numerator and denominator are flipped. So this behaviour has been there 
unreported for at least 36 years. The version in 1983 was all written in 
upper case letters and did not deal with the nth root cases - only the 
sqrt case. Perhaps this integral is not one that arises terribly often as 
a natural problem needing to be solved!

I have little doubt that when somebody looks harder at the very least the 
infinite loop can be disposed of so that the integral can fail to be 
evaluated but in a sensible amount of time & space.

Arthur



=============================
on echo;
int(x,x); % to get package loaded
lisp verbos t;
lisp enable!-errorset(3,3);
tr transcendentalcase, sqrt2top, multoutdenr;
on trint;
symbolic procedure aftergcsystemhook u;
       error(1234, "gchappens");

int(
  x*(1+x)^(2/3)*(1-x)^(1/2)/(-(1-x)^(5/6)*(1+x)^(1/3)+(1-x)^(2/3)*(1+x)^(1/2))
  ,x);

quit;
=============================