1 | initial version |

[ Too long for a comment. Not a definitive answer... ]

I don't agree that this is a bug :

In both Sage and Fricas, the logarithm function is called

`log`

. Sage happens to support a synonym called`ln`

in order to support CASes that call their logarithm function`ln`

(Maple, IIRC).In Sage, the first argument of

`integrate`

is a symbolic expression or something than can be understood as such (e. g. a symbolic function, a. k. a. callable symbolic expressin).For now, this is done by passing this argument to

`SR`

.It

*happens*that passing a string to`SR`

*attempts*to create a symbolic expression whose string representation is theis string. Therefore, in*happens*that `integrate("log(x)", x) is understood .

*But this is an undocumented and unsupported behaviour.*

- When you call
`integrate("log(x)", x), algorithm="fricas")`

, you invoke a totally different mechanism: you pass the*raw string*`"log(x)`

to the Fricas interpreter, which somehow manages to parse it and*happens*to return the expected answer,*because it recognozes the string "log(x)" as the string representation of the logarithm function applied to x*.

** But this is ALSO an undocumented and unsupported behaviour.** The documentation for the

`integrate`

function states that the function will call the `integral`

method of its first argument. You can check for yourself that (Python) strings have no `integral`

method ; the `SR`

call is just an implementation detail that, being undocumented, - Therefore, when you call
`integrate("log(x)", x), algorithm="fricas")`

, the Fricas interpreter has no information whatsoever about a function whose string representation is`"ln"`

. Therefore, it manages it as an undefined function.

The "bug" is therefore the use of the `integrate`

function on arguments not documented to be acceptable...

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.