Revision history [back]
 | 1 | initial version |
The bug is actually that integrate("ln(x)",x) returns a recognizable answer. The Fricas behaviour is actually closer to the semantics that sage is aware of at this point. The string "ln(x)" doesn't actually get turned into a symbolic expression in sage that has the meaning you might hope it has. Compare:
sage: SR('ln(x)').diff(x)
diff(ln(x), x)
sage: SR('log(x)').diff(x)
1/x
With SR("ln(x)"), you create a "formal" function (like SR("f(x)")). It just happens to be translated to a function with string representation "ln" in maxima, where it collides with the ln/log functions that maxima is aware of. If we would translate formal functions to _SAGE_FUNC_ln like we translate x into the maxima symbol _SAGE_VAR_x, this collision wouldn't happen.
The reason why ln(x) does work in sage is because the name ln is bound to a function with print name log that knows how to be differentiated and translated in various interfaces (including maxima and fricas).
It is NOT the case that the integrate("ln(x)",algorithm="fricas") passes the string "ln(x)" to the fricas interface directly: python strings don't have an integral method. So the argument ln(x) gets cast into SR first.
