#4383 great not transitive (so simplifya not idempotent)

[Barton Willis]

Test 265 of rtest_integrate has a comment saying that "The expand(XXX,0,0) is due to a bug--the antiderivative is unsimplified." No, I think it's worse than that--the problem is that 'simplifya' isn't idempotent. Observe how the factor of 'd' changes position in the denominator:

(%i1)   XXX :  integrate(a^(d*z) * h^(c*z),z);

"Is "(c*log(h))/(log(a)*d)" equal to "-1"?"n;
(XXX)   (a^(d*z))^((c*log(h))/(log(a)*d)+1)/(log(a)*d*((c*log(h))/(log(a)*d)+1))

(%i2)   expand(XXX,0,0);
(%o2)   (a^(d*z))^((c*log(h))/(log(a)*d)+1)/(log(a)*((c*log(h))/(log(a)*d)+1)*d)

(%i3)   expand(%,0,0);
(%o3)   (a^(d*z))^((c*log(h))/(log(a)*d)+1)/(log(a)*d*((c*log(h))/(log(a)*d)+1))

(%i4)   expand(%,0,0);
(%o4)   (a^(d*z))^((c*log(h))/(log(a)*d)+1)/(log(a)*d*((c*log(h))/(log(a)*d)+1))

(%i5)   expand(%,0,0);
(%o5)   (a^(d*z))^((c*log(h))/(log(a)*d)+1)/(log(a)*((c*log(h))/(log(a)*d)+1)*d)

(%i6)   expand(%,0,0);
(%o6)   (a^(d*z))^((c*log(h))/(log(a)*d)+1)/(log(a)*d*((c*log(h))/(log(a)*d)+1))

[Barton Willis]

Another example (Maxima 5.47):

(%i1)   domain : complex$
(%i2)   declare(z,complex)$
(%i3)   X : exp(z) +  sqrt(exp(z))$

(%i4)   expand(X,0,0);
(%o4)   sqrt(%e^z)+%e^z

(%i5)   expand(%,0,0);
(%o5)   %e^z+sqrt(%e^z)

(%i6)   expand(%,0,0);
(%o6)   sqrt(%e^z)+%e^z

(%i7)   expand(%,0,0);
(%o7)   %e^z+sqrt(%e^z)

[Stavros Macrakis]

domain : complex$
declare(z,complex)$
orderlessp(exp(z),sqrt(exp(z))) => false
orderlessp(sqrt(exp(z)),exp(z)) => false

Maxima 5.47.0 SBCL 2.4.7 MacOS

[Stavros Macrakis]

Here is a simpler case of the original problem:

(a^(b*d))^f(c)/(b*f(c)) => (a^(b*d))^f(c)/(b*f(c))
expand(%,0,0) => (a^(b*d))^f(c)/(f(c)*b)

Interestingly, this depends critically on the variable names being in that order. I tried all the permutations of variable orders, and only this order was problematic. The function name didn't matter.
For example,

(b^(a*d))^f(c)/(f(c)*d)

is unchanged by expand.

So this suggests that the problem is in great/orderlessp, as it was in the Methuselah bug. So I tested orderlessp and found the following cases where it is not transitive:

bad: '[
[f(b),a^(b*c),b],
[a^(b*c),b,f(b)], 
[b,f(b),a^(b*c)]
]

For each of these cases, orderlessp(l[1],l[2]) and orderlessp(l[2],l[3]) are true, but orderlessp(l[1],l[3]) is false.

This means that the result of sort depends on the order of the inputs:

for i in bad do if (si:sort(i))#(sri:sort(reverse(i))) then print("Bad:", si, sri) =>
Bad: [f(b),a^(b*c),b] [a^(b*c),b,f(b)] 
Bad: [a^(b*c),b,f(b)] [b,f(b),a^(b*c)] 
Bad: [b,f(b),a^(b*c)] [f(b),a^(b*c),b] 

This of course also breaks other functions that depend on ordering:

setify([b,f(b),f(c),a^(b*d),b]) => {b,f(b),f(c),a^(b*d),b}

Tested in Maxima 5.47.0 SBCL 2.4.7 MacOS

[Barton Willis]

The bug

(%i1)   (domain : complex,declare(z,complex))$

(%i2)   orderlessp(exp(z),sqrt(exp(z)));
(%o2)   false

(%i3)   orderlessp(sqrt(exp(z)),exp(z));
(%o3)   false

is almost surely caused by the function ordmexpt (defined in simp.lisp). Specifically, the offending function is (with a comment inserted by me about the offending lines)

(defun ordmexpt (x y)
  (cond ((eq (caar y) 'mexpt)
     (cond ((alike1 (cadr x) (cadr y)) (great (caddr x) (caddr y)))
           ((maxima-constantp (cadr x))
        (if (maxima-constantp (cadr y))
            (if (or (alike1 (caddr x) (caddr y))
                (and (mnump (caddr x)) (mnump (caddr y))))
            (great (cadr x) (cadr y))
            (great (caddr x) (caddr y)))
            (great x (cadr y))))

            ;; The next two clauses are, I think, the cause of bug #4383. But 
            ;; commenting them out causes about 221 testsuite failures. Many of the
            ;; failures are just syntactic, but some failures are semantic.  
           ((maxima-constantp (cadr y)) (great (cadr x) y))

           ((mnump (caddr x))
        (great (cadr x) (if (mnump (caddr y)) (cadr y) y)))


           ((mnump (caddr y)) (great x (cadr y)))
           (t (let ((x1 (simpln1 x)) (y1 (simpln1 y)))
            (if (alike1 x1 y1) (great (cadr x) (cadr y))
            (great x1 y1))))))
    ((alike1 (cadr x) y) (great (caddr x) 1))
    ((mnump (caddr x)) (great (cadr x) y))
    (t (great (simpln1 x)
          (ftake '%log y)))))

This function is supposed to be a syntactic, not semantic, comparison. For that reason, the way the function compares expressions after applying simpln1 and %log makes me uncomfortable. There are lots of option variables that alter the way log expressions are simplified, so comparing the logarithms of the expressions seems like a potential problem.

Also, the function maxima-constantp doesn't catch most (any?) non-atomic constants, so using it seems wrong.

[Barton Willis]

Other such bugs are not hard to find--just define a list of expressions and test all triples from the list. Using this method, I found 100s of examples of these bugs; here is an example:

~~~
LL : sort([-(1/c^%pi),-(1/(1/c)^%pi),b*c])$

orderlessp(first(LL), second(LL));
true

orderlessp(second(LL), third(LL));
true

orderlessp(first(LL), third(LL));
false

~~~

[Dan Gildea]

See proposed solution in [#3072]

[Barton Willis]

Fixed by Commit [227d11]. Closing this ticket.