to_poly_solve tries to expunge spurious solutions:
(%i1) f:(x^2*(x+3))^(1/3)$
(%i2) to_poly_solve(diff(f,x,2),x);
(%o2) %union()
(%i3) to_poly_solve(ratsimp(diff(f,x,2)),x);
(%o3) %union()
As far as I know, the function solve doesn't check for zero divisors; for example
(%i4) solve(sin(x)/x,x);
(%o4) [x=0]
A related example is
(%i1) solve(x/x=1,x);
(%o1) all
The general simplifier does x/x --> 1 before solve is called. Thus solve doesn't have a chance. Finally,
ratsimp cancels common nonconstant factors; thus ratsimp should generally be thought of as an
almost everywhere simplification:
(%i9) ratsimp((x^2-4)/(x-2));
(%o9) x+2
I say "generally be thought" because
(%i16) g : (abs(x)+x)/(x*abs(x)+6*abs(x)+x^2+6*x)$
(%i17) ratsimp(g);
(%o17) 1/(x+6)
is wrong on the entire negative real axis. Carbon based computing is still a worthwhile endeavor.
--Barton
________________________________
Look at this example:
f:(x^2*(x+3))^(1/3);
f1:diff(f,x);
solve(f1);
x=2;
f2:diff(f1,x);
solve(f2);
[ ]
f3:ratsimp(f2);
solve(f3);
x=-3
If I solve f2, it is correct, but if I solve f3, it is not correct, x=-3 is out of domain in f2.
Best regards.
Luigi Marino