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

asked 2019-12-27 15:43:14 +0200

dsejas
2819 ●14 ●49 ●95

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.

In order to see more detail about this process, and a possible point where things go wrong, please see the answer to this question.

Thanks in advance!

edit retag flag offensive close merge delete

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2019-12-30 07:44:24 +0200

nbruin
4143 ●3 ●45 ●90

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.

edit flag offensive delete link

Comments

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

Emmanuel Charpentier ( 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.

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

add a comment

answered 2019-12-27 17:49:07 +0200

Emmanuel Charpentier
7057 ●6 ●46 ●137

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

edit flag offensive delete link

Comments

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.

Well, I think your "answer" is a correct answer. I am ticking it as correct.

dsejas ( 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.

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

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

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

2 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

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

2 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

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