ASKSAGE: Sage Q&A Forum - Individual question feedhttp://ask.sagemath.org/questions/Q&A Forum for SageenCopyright Sage, 2010. Some rights reserved under creative commons license.Mon, 30 Dec 2019 10:37:51 -0600Possible bug needs confirmation: Fricas can't handle "ln"http://ask.sagemath.org/question/49221/possible-bug-needs-confirmation-fricas-cant-handle-ln/ Hello, Sage Community!
Based on [this question](https://ask.sagemath.org/question/49215/confusion-about-integrating-a-string/) 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](https://ask.sagemath.org/question/49215/confusion-about-integrating-a-string/).
Thanks in advance!Fri, 27 Dec 2019 08:43:14 -0600http://ask.sagemath.org/question/49221/possible-bug-needs-confirmation-fricas-cant-handle-ln/Answer by nbruin for <p>Hello, Sage Community!</p>
<p>Based on <a href="https://ask.sagemath.org/question/49215/confusion-about-integrating-a-string/">this question</a> by user <a href="/users/7931/nasser/">@Nasser</a>, and follow up comments, there seems to be a bug in SageMath. The following statement is syntactically correct:</p>
<pre><code>integrate('ln(x)', x, algorithm='fricas')
</code></pre>
<p>but it returns <code>integral(ln(x), x)</code>, which is indeed correct, but not expected. The equivalent statement</p>
<pre><code>integrate(ln(x), x, algorithm='fricas')
</code></pre>
<p>returns the expected answer, 'x*log(x) - x'.</p>
<p>The problem seems to be that <code>ln</code> is not defined in Fricas, but <code>log</code> is. When Fricas receives an unknown function---let's say <code>func</code>---, it returns the abstract integral</p>
<pre><code> t
++
| func(%A)d%A
++
</code></pre>
<p>which is converted by Sage to</p>
<pre><code>integral(func(x), x)
</code></pre>
<p>And that is what happens with <code>ln</code>: Sage uses the Symbolic Ring <code>SR</code> to convert the string <code>'ln(x)'</code> to a symbolic math function, but then, it doesn't convert it to <code>log(x)</code>, and passes <code>ln(x)</code> to Fricas, which is a unknown function for it. So, an abstract integral is returned.</p>
<p>As <a href="/users/7931/nasser/">@Nasser</a> points out:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>I have to agree with this statement. SageMath should handle the adequate conversion for the CAS it passes its input.</p>
<p>In order to see more detail about this process, and a possible point where things go wrong, please see <a href="https://ask.sagemath.org/question/49215/confusion-about-integrating-a-string/">the answer to this question</a>.</p>
<p>Thanks in advance!</p>
http://ask.sagemath.org/question/49221/possible-bug-needs-confirmation-fricas-cant-handle-ln/?answer=49254#post-id-49254The 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.Mon, 30 Dec 2019 00:44:24 -0600http://ask.sagemath.org/question/49221/possible-bug-needs-confirmation-fricas-cant-handle-ln/?answer=49254#post-id-49254Comment by dsejas for <p>The bug is actually that <code>integrate("ln(x)",x)</code> returns a recognizable answer. The Fricas behaviour is actually closer to the semantics that sage is aware of at this point. The string <code>"ln(x)"</code> doesn't actually get turned into a symbolic expression in sage that has the meaning you might hope it has. Compare:</p>
<pre><code>sage: SR('ln(x)').diff(x)
diff(ln(x), x)
sage: SR('log(x)').diff(x)
1/x
</code></pre>
<p>With <code>SR("ln(x)")</code>, you create a "formal" function (like <code>SR("f(x)")</code>). It just happens to be translated to a function with string representation "ln" in maxima, where it collides with the <code>ln/log</code> functions that maxima is aware of. If we would translate formal functions to <code>_SAGE_FUNC_ln</code> like we translate <code>x</code> into the maxima symbol <code>_SAGE_VAR_x</code>, this collision wouldn't happen.</p>
<p>The reason why <code>ln(x)</code> does work in sage is because the name <code>ln</code> is bound to a function with print name <code>log</code> that knows how to be differentiated and translated in various interfaces (including maxima and fricas).</p>
<p>It is <strong>NOT</strong> 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 <code>integral</code> method. So the argument <code>ln(x)</code> gets cast into SR first.</p>
http://ask.sagemath.org/question/49221/possible-bug-needs-confirmation-fricas-cant-handle-ln/?comment=49262#post-id-49262OK, 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.Mon, 30 Dec 2019 10:37:51 -0600http://ask.sagemath.org/question/49221/possible-bug-needs-confirmation-fricas-cant-handle-ln/?comment=49262#post-id-49262Comment by Emmanuel Charpentier for <p>The bug is actually that <code>integrate("ln(x)",x)</code> returns a recognizable answer. The Fricas behaviour is actually closer to the semantics that sage is aware of at this point. The string <code>"ln(x)"</code> doesn't actually get turned into a symbolic expression in sage that has the meaning you might hope it has. Compare:</p>
<pre><code>sage: SR('ln(x)').diff(x)
diff(ln(x), x)
sage: SR('log(x)').diff(x)
1/x
</code></pre>
<p>With <code>SR("ln(x)")</code>, you create a "formal" function (like <code>SR("f(x)")</code>). It just happens to be translated to a function with string representation "ln" in maxima, where it collides with the <code>ln/log</code> functions that maxima is aware of. If we would translate formal functions to <code>_SAGE_FUNC_ln</code> like we translate <code>x</code> into the maxima symbol <code>_SAGE_VAR_x</code>, this collision wouldn't happen.</p>
<p>The reason why <code>ln(x)</code> does work in sage is because the name <code>ln</code> is bound to a function with print name <code>log</code> that knows how to be differentiated and translated in various interfaces (including maxima and fricas).</p>
<p>It is <strong>NOT</strong> 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 <code>integral</code> method. So the argument <code>ln(x)</code> gets cast into SR first.</p>
http://ask.sagemath.org/question/49221/possible-bug-needs-confirmation-fricas-cant-handle-ln/?comment=49255#post-id-49255Nils is right. His explanation is much better than mine, which was too fast.Mon, 30 Dec 2019 02:23:38 -0600http://ask.sagemath.org/question/49221/possible-bug-needs-confirmation-fricas-cant-handle-ln/?comment=49255#post-id-49255Answer by Emmanuel Charpentier for <p>Hello, Sage Community!</p>
<p>Based on <a href="https://ask.sagemath.org/question/49215/confusion-about-integrating-a-string/">this question</a> by user <a href="/users/7931/nasser/">@Nasser</a>, and follow up comments, there seems to be a bug in SageMath. The following statement is syntactically correct:</p>
<pre><code>integrate('ln(x)', x, algorithm='fricas')
</code></pre>
<p>but it returns <code>integral(ln(x), x)</code>, which is indeed correct, but not expected. The equivalent statement</p>
<pre><code>integrate(ln(x), x, algorithm='fricas')
</code></pre>
<p>returns the expected answer, 'x*log(x) - x'.</p>
<p>The problem seems to be that <code>ln</code> is not defined in Fricas, but <code>log</code> is. When Fricas receives an unknown function---let's say <code>func</code>---, it returns the abstract integral</p>
<pre><code> t
++
| func(%A)d%A
++
</code></pre>
<p>which is converted by Sage to</p>
<pre><code>integral(func(x), x)
</code></pre>
<p>And that is what happens with <code>ln</code>: Sage uses the Symbolic Ring <code>SR</code> to convert the string <code>'ln(x)'</code> to a symbolic math function, but then, it doesn't convert it to <code>log(x)</code>, and passes <code>ln(x)</code> to Fricas, which is a unknown function for it. So, an abstract integral is returned.</p>
<p>As <a href="/users/7931/nasser/">@Nasser</a> points out:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>I have to agree with this statement. SageMath should handle the adequate conversion for the CAS it passes its input.</p>
<p>In order to see more detail about this process, and a possible point where things go wrong, please see <a href="https://ask.sagemath.org/question/49215/confusion-about-integrating-a-string/">the answer to this question</a>.</p>
<p>Thanks in advance!</p>
http://ask.sagemath.org/question/49221/possible-bug-needs-confirmation-fricas-cant-handle-ln/?answer=49225#post-id-49225[ 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...Fri, 27 Dec 2019 10:49:07 -0600http://ask.sagemath.org/question/49221/possible-bug-needs-confirmation-fricas-cant-handle-ln/?answer=49225#post-id-49225Comment by dsejas for <p>[ Too long for a comment. Not a definitive answer... ]</p>
<p>I don't agree that this is a bug :</p>
<ul>
<li><p>In both Sage and Fricas, the logarithm function is called <code>log</code>. Sage happens to support a synonym called <code>ln</code> in order to support CASes that call their logarithm function <code>ln</code> (Maple, IIRC).</p></li>
<li><p>In Sage, the first argument of <code>integrate</code> is a symbolic expression or something than can be understood as such (e. g. a symbolic function, a. k. a. callable symbolic expressin).</p></li>
<li><p>For now, this is done by passing this argument to <code>SR</code>.</p></li>
<li><p>It <em>happens</em> that passing a string to <code>SR</code> <em>attempts</em> to create a symbolic expression whose string representation is theis string. Therefore, in <em>happens</em> that `integrate("log(x)", x) is understood .</p></li>
</ul>
<p><strong><em>But this is an undocumented and unsupported behaviour.</em></strong></p>
<ul>
<li>When you call <code>integrate("log(x)", x), algorithm="fricas")</code>, you invoke a totally different mechanism: you pass the <em>raw string</em> <code>"log(x)</code> to the Fricas interpreter, which somehow manages to parse it and <em>happens</em> to return the expected answer, <em>because it recognozes the string "log(x)" as the string representation of the logarithm function applied to x</em>.</li>
</ul>
<p><strong><em>But this is ALSO an undocumented and unsupported behaviour.</em></strong> The documentation for the <code>integrate</code> function states that the function will call the <code>integral</code> method of its first argument. You can check for yourself that (Python) strings have no <code>integral</code> method ; the <code>SR</code> call is just an implementation detail that, being undocumented, <strong><em>cannot</em> be relied upon.</strong></p>
<ul>
<li>Therefore, when you call <code>integrate("log(x)", x), algorithm="fricas")</code>, the Fricas interpreter has no information whatsoever about a function whose string representation is <code>"ln"</code>. Therefore, it manages it as an undefined function.</li>
</ul>
<p>The "bug" is therefore the use of the <code>integrate</code> function on arguments not documented to be acceptable...</p>
http://ask.sagemath.org/question/49221/possible-bug-needs-confirmation-fricas-cant-handle-ln/?comment=49230#post-id-49230One 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.Fri, 27 Dec 2019 11:20:22 -0600http://ask.sagemath.org/question/49221/possible-bug-needs-confirmation-fricas-cant-handle-ln/?comment=49230#post-id-49230Comment by dsejas for <p>[ Too long for a comment. Not a definitive answer... ]</p>
<p>I don't agree that this is a bug :</p>
<ul>
<li><p>In both Sage and Fricas, the logarithm function is called <code>log</code>. Sage happens to support a synonym called <code>ln</code> in order to support CASes that call their logarithm function <code>ln</code> (Maple, IIRC).</p></li>
<li><p>In Sage, the first argument of <code>integrate</code> is a symbolic expression or something than can be understood as such (e. g. a symbolic function, a. k. a. callable symbolic expressin).</p></li>
<li><p>For now, this is done by passing this argument to <code>SR</code>.</p></li>
<li><p>It <em>happens</em> that passing a string to <code>SR</code> <em>attempts</em> to create a symbolic expression whose string representation is theis string. Therefore, in <em>happens</em> that `integrate("log(x)", x) is understood .</p></li>
</ul>
<p><strong><em>But this is an undocumented and unsupported behaviour.</em></strong></p>
<ul>
<li>When you call <code>integrate("log(x)", x), algorithm="fricas")</code>, you invoke a totally different mechanism: you pass the <em>raw string</em> <code>"log(x)</code> to the Fricas interpreter, which somehow manages to parse it and <em>happens</em> to return the expected answer, <em>because it recognozes the string "log(x)" as the string representation of the logarithm function applied to x</em>.</li>
</ul>
<p><strong><em>But this is ALSO an undocumented and unsupported behaviour.</em></strong> The documentation for the <code>integrate</code> function states that the function will call the <code>integral</code> method of its first argument. You can check for yourself that (Python) strings have no <code>integral</code> method ; the <code>SR</code> call is just an implementation detail that, being undocumented, <strong><em>cannot</em> be relied upon.</strong></p>
<ul>
<li>Therefore, when you call <code>integrate("log(x)", x), algorithm="fricas")</code>, the Fricas interpreter has no information whatsoever about a function whose string representation is <code>"ln"</code>. Therefore, it manages it as an undefined function.</li>
</ul>
<p>The "bug" is therefore the use of the <code>integrate</code> function on arguments not documented to be acceptable...</p>
http://ask.sagemath.org/question/49221/possible-bug-needs-confirmation-fricas-cant-handle-ln/?comment=49228#post-id-49228I 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.Fri, 27 Dec 2019 11:05:04 -0600http://ask.sagemath.org/question/49221/possible-bug-needs-confirmation-fricas-cant-handle-ln/?comment=49228#post-id-49228