Revision history [back]

[ 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, cannot be relied upon.

• 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...