# Possible bug needs confirmation: Fricas can't handle "ln"

Hello, Sage Community!

Based on this question by user @Nasser, and follow up comments, there seems to be a bug in SageMath. The following statement is syntactically correct:

integrate('ln(x)', x, algorithm='fricas')


but it returns integral(ln(x), x), which is indeed correct, but not expected. The equivalent statement

integrate(ln(x), x, algorithm='fricas')


returns the expected answer, 'x*log(x) - x'.

The problem seems to be that ln is not defined in Fricas, but log is. When Fricas receives an unknown function---let's say func---, it returns the abstract integral

   t
++
|   func(%A)d%A
++


which is converted by Sage to

integral(func(x), x)


And that is what happens with ln: Sage uses the Symbolic Ring SR to convert the string 'ln(x)' to a symbolic math function, but then, it doesn't convert it to log(x), and passes ln(x) to Fricas, which is a unknown function for it. So, an abstract integral is returned.

As @Nasser points out:

But I am using sagemath? If a user has to know what each other CAS system that sagemath uses prefer or not prefer in terms of the input, what is the point then of using Sagemath? One can just use the other CAS system. I mean, I am using ln(t) which Sagemath knows, right? A user should not care if the system that sagemath ends up calling to do the integration knows or not know about ln(t). Sagemath should have then converted ln(t) automatically internally to log(t) in this case. At least this is what I would have expected. But thanks for the answer. I changed my calls to use "log(t)" and issue resolved for me.

I have to agree with this statement. SageMath should handle the adequate conversion for the CAS it passes its input.

edit retag close merge delete

Sort by » oldest newest most voted

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.

more

Nils is right. His explanation is much better than mine, which was too fast.

( 2019-12-30 09:23:38 +0200 )edit

OK, I have marked it as the correct answer. Although I still like Emmanuel's answer, I agree that this one will be more helpful for the users.

( 2019-12-30 17:37:51 +0200 )edit

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

more

I understand. So, the fact that SageMath can integrate strings is an unintended consequence of the use of SR in the inthegrate()` function. Maybe I should modify one of my previous answers related to this matter.

( 2019-12-27 18:05:04 +0200 )edit

One more thing, @Emmanuel Charpentier. Shouldn't there be an error message when trying to integrate a string? Maybe this is actually a bug, but in a different manner than I thought.

( 2019-12-27 18:20:22 +0200 )edit