I have worked on the bug report ID: 2184396 "Wrong factorization of
sqrt()". As reported it is a problem of the function sign which
determines the sign of expressions like (1-(1+sqrt(2))*x) wrongly.
I think I have found the bug in the routine compsplt.
(defun compsplt (x)
(cond ((atom x) (setq lhs x rhs 0))
((atom (car x)) (setq lhs x rhs 0))
---> ((not (null (cdr (symbols x)))) (compsplt2 x))
(t (compsplt1 x))))
At the marked line Maxima tests the CDR of the result of the function
SYMBOLS. SYMBOLS returns a list of all variables of an expression. The
list is of the form '($X $Y ...), where $X, $Y are the variables.
Because COMPSPLT takes the CDR of SYMBOLS, one symbol in an expression
is not recognized. Later in the algorithm the sign of this variable is
not taken into account.
For almost all expression this behaviour seems to be no problem, but not
for the example of this bug report.
When we change the test of the marked line:
((not (null (symbols x))) ...
the sign of the given examples of this bug report are correct:
(%i3) sign(1-(2+sqrt(2))*x);
(%o3) pnz
(%i4) sign(1-(2+sqrt(2))/x);
(%o4) pnz
and the reported expression does not longer factorize wrongly:
(%i5) sqrt((1-(2-sqrt(2))/x)*((2+sqrt(2))/x-1));
(%o5) sqrt((1-(2-sqrt(2))/x)*((sqrt(2)+2)/x-1))
One example of the testsuite no longer works. It is one of the new
examples for the sign of the abs function. This is the example:
(%i2) assume(abs(x)<%e/2+sin(1));
(%o2) [sin(1)+%e/2 > abs(x)]
(%i3) is(x>-2*%e);
(%o3) true
This will be the new result:
(%i6) assume(abs(x)<%e/2+sin(1));
(%o6) [-abs(x)+sin(1)+%e/2 > 0]
(%i7) is(x>-2*%e);
(%o7) unknown
This test no longer works, because the ordering of the terms will
change. The reason is that COMPSPLT calls splitsum for one variable x in
the expression too.
So, with one exception the testsuite and the share_testsuite have no
problems with the suggested change in COMPSPLT.
Dieter Kaiser