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.

Copyright Sage, 2010. Some rights reserved under creative commons license. Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.