Sage: Ticket #12731: Stopgap for #11590
https://trac.sagemath.org/ticket/12731
<p>
Can someone more knowledgeable about using maxima for integration determine what the right warning to show is and when to show it? See <a class="closed ticket" href="https://trac.sagemath.org/ticket/12691" title="#12691: enhancement: Create a stopgap warning (closed: fixed)">#12691</a> for what a stopgap is.
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/12731
Trac 1.2Karl-Dieter CrismanFri, 23 Mar 2012 01:02:28 GMT
https://trac.sagemath.org/ticket/12731#comment:1
https://trac.sagemath.org/ticket/12731#comment:1
<p>
I'm not really sure that this is appropriate for a stopgap. I mean, unless we put in a catch for the <em>specific</em> form like <code>integrate(x * sgn(x^2 - 1/4), x, -1, 0)</code>, we would have to put in a stopgap for the entire integration, which is ridiculous.
</p>
<p>
Unless we checked for the signum function with nonlinear operands in it sometime... but that's more than I have time to parse now.
</p>
TicketJeroen DemeyerSun, 08 Apr 2012 08:52:50 GMTpriority changed
https://trac.sagemath.org/ticket/12731#comment:2
https://trac.sagemath.org/ticket/12731#comment:2
<ul>
<li><strong>priority</strong>
changed from <em>blocker</em> to <em>major</em>
</li>
</ul>
TicketJeroen DemeyerTue, 13 Aug 2013 15:35:53 GMTmilestone changed
https://trac.sagemath.org/ticket/12731#comment:3
https://trac.sagemath.org/ticket/12731#comment:3
<ul>
<li><strong>milestone</strong>
changed from <em>sage-5.11</em> to <em>sage-5.12</em>
</li>
</ul>
TicketFor batch modificationsThu, 30 Jan 2014 21:20:52 GMTmilestone changed
https://trac.sagemath.org/ticket/12731#comment:4
https://trac.sagemath.org/ticket/12731#comment:4
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.1</em> to <em>sage-6.2</em>
</li>
</ul>
TicketFor batch modificationsTue, 06 May 2014 15:20:58 GMTmilestone changed
https://trac.sagemath.org/ticket/12731#comment:5
https://trac.sagemath.org/ticket/12731#comment:5
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.2</em> to <em>sage-6.3</em>
</li>
</ul>
TicketFor batch modificationsSun, 10 Aug 2014 16:51:03 GMTmilestone changed
https://trac.sagemath.org/ticket/12731#comment:6
https://trac.sagemath.org/ticket/12731#comment:6
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.3</em> to <em>sage-6.4</em>
</li>
</ul>
TicketKarl-Dieter CrismanMon, 08 Dec 2014 15:00:04 GMTcc, description, summary changed
https://trac.sagemath.org/ticket/12731#comment:7
https://trac.sagemath.org/ticket/12731#comment:7
<ul>
<li><strong>cc</strong>
<em>Peter Bruin</em> <em>Ralf Stephan</em> added
</li>
<li><strong>description</strong>
modified (<a href="/ticket/12731?action=diff&version=7">diff</a>)
</li>
<li><strong>summary</strong>
changed from <em>Stopgap for #11590</em> to <em>Disable abs_integrate as default</em>
</li>
</ul>
TicketKarl-Dieter CrismanMon, 08 Dec 2014 15:02:10 GMTsummary changed
https://trac.sagemath.org/ticket/12731#comment:8
https://trac.sagemath.org/ticket/12731#comment:8
<ul>
<li><strong>summary</strong>
changed from <em>Disable abs_integrate as default</em> to <em>Disable or raise warning with abs_integrate as default</em>
</li>
</ul>
<p>
Naturally, if it becomes unnecessary to do so, we can just close this as wontfix. This is the best equivalent to a stopgap I can come up with - or possibly we can raise a warning every time <code>abs_integrate</code> is used, though this won't stop the hangs and other weird interactions it causes.
</p>
TicketKarl-Dieter CrismanMon, 15 Dec 2014 16:20:03 GMTdescription changed
https://trac.sagemath.org/ticket/12731#comment:9
https://trac.sagemath.org/ticket/12731#comment:9
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/12731?action=diff&version=9">diff</a>)
</li>
</ul>
TicketKarl-Dieter CrismanMon, 15 Dec 2014 20:05:04 GMT
https://trac.sagemath.org/ticket/12731#comment:10
https://trac.sagemath.org/ticket/12731#comment:10
<p>
Unfortunately, a lot of the most popular such integrals are not computed with sympy (yet?). Not even <code>abs(x)</code>.
</p>
<pre class="wiki">In [1]: from sympy import *
In [2]: x=Symbol('x')
In [3]: integrate( abs(x), x)
Out[3]: Integral(Abs(x), x)
In [4]: integrate( abs(x), (x, 0, 1))
Out[4]: Integral(Abs(x), (x, 0, 1))
</pre>
TicketKarl-Dieter CrismanMon, 15 Dec 2014 20:09:58 GMT
https://trac.sagemath.org/ticket/12731#comment:11
https://trac.sagemath.org/ticket/12731#comment:11
<p>
Useful comment from author of <code>abs_integrate</code>:
</p>
<blockquote class="citation">
<p>
The assignments extra_definite_integration_methods : [] and extra_integration_methods : [] should render abs_integrate inoperative.
Resorting these lists to their defaults will revive abs_integrate. A kill(all) will remove all traces of abs_integrate--a reload is needed.
</p>
</blockquote>
<p>
So we could conceivably do this in the case that Maxima (or whomever) returns an unevaluated integral, sort of like what we do with solving.
</p>
TicketJakob KroekerTue, 10 Feb 2015 00:50:05 GMT
https://trac.sagemath.org/ticket/12731#comment:12
https://trac.sagemath.org/ticket/12731#comment:12
<p>
could all developers involved in this ticket eventually meditate on Williams comment:
</p>
<blockquote class="citation">
<p>
And why are we using it (abs_integrate) if it is so broken -- it should
require an explicit flag to use at all. Sage is supposed to <strong>default</strong>
to correct answers unless you otherwise explicitly request otherwise
</p>
</blockquote>
<p>
Does that sound reasonable?
</p>
TicketRalf StephanSat, 07 Mar 2015 07:05:41 GMTpriority, milestone changed
https://trac.sagemath.org/ticket/12731#comment:13
https://trac.sagemath.org/ticket/12731#comment:13
<ul>
<li><strong>priority</strong>
changed from <em>major</em> to <em>critical</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage-6.4</em> to <em>sage-6.6</em>
</li>
</ul>
TicketRalf StephanSat, 07 Mar 2015 10:01:21 GMTsummary changed
https://trac.sagemath.org/ticket/12731#comment:14
https://trac.sagemath.org/ticket/12731#comment:14
<ul>
<li><strong>summary</strong>
changed from <em>Disable or raise warning with abs_integrate as default</em> to <em>Disable abs_integrate</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12731#comment:12" title="Comment 12">jakobkroeker</a>:
</p>
<blockquote class="citation">
<p>
could all developers involved in this ticket eventually meditate on Williams comment:
</p>
<blockquote class="citation">
<p>
And why are we using it (abs_integrate) if it is so broken -- it should
require an explicit flag to use at all. Sage is supposed to <strong>default</strong>
to correct answers unless you otherwise explicitly request otherwise
</p>
</blockquote>
<p>
Does that sound reasonable?
</p>
</blockquote>
<p>
Yes, and it's the only option because that package causes so much collateral damage, not only in <code>integrate</code>. Turning it off only triggers a few minor doctest failures, most of them (9) in <code>interfaces/maxima_lib.py</code>.
</p>
TicketRalf StephanSat, 07 Mar 2015 15:58:20 GMTbranch set
https://trac.sagemath.org/ticket/12731#comment:15
https://trac.sagemath.org/ticket/12731#comment:15
<ul>
<li><strong>branch</strong>
set to <em>u/rws/disable_abs_integrate</em>
</li>
</ul>
TicketRalf StephanSat, 07 Mar 2015 16:02:53 GMTcommit set
https://trac.sagemath.org/ticket/12731#comment:16
https://trac.sagemath.org/ticket/12731#comment:16
<ul>
<li><strong>commit</strong>
set to <em>4790fc753098c35bbd5d2580b77f77ac511f3fdd</em>
</li>
</ul>
<p>
This commit removes the package, fixes/moves doctests. I have put those doctests testing the <code>abs_integrate</code> package into the wishlist <a class="new ticket" href="https://trac.sagemath.org/ticket/17910" title="#17910: task: unsolved piecewise integrals metaticket (new)">#17910</a>.
</p>
<p>
If someone is not comfortable doing this "silently", using expression tree walking I could add checks for <code>abs</code> and <code>sgn</code> and output ... what? Note, some integrals are now solved by Maxima proper.
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=4790fc753098c35bbd5d2580b77f77ac511f3fdd"><span class="icon"></span>4790fc7</a></td><td><code>12731: don't load abs_integrate; move/fix/remove doctests</code>
</td></tr></table>
TicketRalf StephanSat, 07 Mar 2015 16:03:54 GMTstatus changed
https://trac.sagemath.org/ticket/12731#comment:17
https://trac.sagemath.org/ticket/12731#comment:17
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_info</em>
</li>
</ul>
TicketNils BruinSat, 07 Mar 2015 16:38:35 GMT
https://trac.sagemath.org/ticket/12731#comment:18
https://trac.sagemath.org/ticket/12731#comment:18
<p>
I think anybody using a computer algebra package for symbolic integration should be aware that results returned might not be correct (or require a different interpretation from what the user would have preferred). However, from the reports listed it seems abs_integrate has particularly numerous issues. It's just not ready for prime time yet. I'd be in favour of ditching it.
</p>
<p>
Incidentally, all those abs_integrate doctests (and the loading of many of the packages) should probably be in calculus. It's got little to do with the interface. Plus, it used to be as simple as changing the assignment to the maxima interface in the calculus file to swap between the library and the expect interface.
</p>
TicketRalf StephanSat, 07 Mar 2015 17:27:54 GMTstatus changed
https://trac.sagemath.org/ticket/12731#comment:19
https://trac.sagemath.org/ticket/12731#comment:19
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>needs_review</em>
</li>
</ul>
TicketKarl-Dieter CrismanSat, 07 Mar 2015 23:42:36 GMT
https://trac.sagemath.org/ticket/12731#comment:20
https://trac.sagemath.org/ticket/12731#comment:20
<p>
I'm really concerned about removing this completely. Even with all the errors, this also introduces a very useful tool, and it makes Sage look just as bad to be constantly changing what functionality it has. This has been in long enough that some sort of deprecation seems necessary, though I'm not sure myself what either.
</p>
<p>
See <a class="ticket" href="https://trac.sagemath.org/ticket/12731#comment:11" title="Comment 11">comment:11</a> for a tip on how to disable/enable it selectively. I have essentially had no Sage development time, nor am likely to in the near future, so I am unable to implement this now. But I think that it would be far better to add some kind of flag or algorithm argument (like with <code>solve()</code>) so that people who want it can still get it. Especially if it still added a stopgap warning.
</p>
<p>
Perhaps one could do a walk for relevant input, as you say in <a class="ticket" href="https://trac.sagemath.org/ticket/12731#comment:16" title="Comment 16">comment:16</a>, and suggest using the flag... <em>or</em> one could check for that input and then send the stopgap message?
</p>
<p>
Again, I'm really sorry I'm unable to help concretely with code at this time (hopefully a little testing).
</p>
TicketRalf StephanSun, 08 Mar 2015 06:47:46 GMT
https://trac.sagemath.org/ticket/12731#comment:21
https://trac.sagemath.org/ticket/12731#comment:21
<p>
So how do you address the fact that, once the package is used, it has destructive side effects on computations, even if you no longer use it and do completely different things. How will you know that an unrelated bug report is not caused by this? What language do you use to prepare the user that, from now on, there might be more problems ahead?
</p>
TicketJakob KroekerSun, 08 Mar 2015 12:06:16 GMT
https://trac.sagemath.org/ticket/12731#comment:22
https://trac.sagemath.org/ticket/12731#comment:22
<blockquote class="citation">
<p>
I'm really concerned about removing this completely.
</p>
</blockquote>
<p>
what is about a kind of experimental mode in sage ?
if enabled by the user, functions like above became available, otherwise they stay out.
</p>
<p>
Personally, I'm against accepting broken or half-baked functionality because as rws says, it is too destructive. I'm experiencing this everyday with Singular CAS. People start using new functionality (which is often only experimental ) and then <strong>almost everything</strong> is broken and cannot be easily fixed. Tests? Ahahaha !! Mathematicians often consider a single example or a couple of examples as as sufficient test...
</p>
TicketMichael OrlitzkySun, 08 Mar 2015 18:53:35 GMT
https://trac.sagemath.org/ticket/12731#comment:23
https://trac.sagemath.org/ticket/12731#comment:23
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12731#comment:21" title="Comment 21">rws</a>:
</p>
<blockquote class="citation">
<p>
So how do you address the fact that, once the package is used, it has destructive side effects on computations, even if you no longer use it and do completely different things. How will you know that an unrelated bug report is not caused by this? What language do you use to prepare the user that, from now on, there might be more problems ahead?
</p>
</blockquote>
<p>
I would rather disable this than have it give wrong answers, but it looks like it should be possible to emit a warning only when abs_integrate is actually used. According to the <a class="ext-link" href="http://maxima.sourceforge.net/docs/manual/de/maxima_31.html#SEC218"><span class="icon"></span>Maxima documentation</a>, there is a list of extra integration methods that maxima will attempt if the standard <code>integrate</code> fails:
</p>
<pre class="wiki">Option variable: extra_integration_methods
Default value: ['signum_int, 'abs_integrate_use_if]
The list extra_integration_methods is a list of functions for integration. When integrate is unable to find an antiderivative, Maxima uses the methods in extra_integration_methods to attempt to determine an antiderivative.
</pre><p>
If we set this variable to the empty list, then no additional integrations will be attempted by Maxima (by default). But, we can still try them ourselves. So we could,
</p>
<ol><li>Try the standard Maxima <code>integrate</code>, and save the result.
</li><li>Try <code>signum_int</code>, and see if the result matches the first one. If it does, ignore it. Otherwise, emit a warning and return the answer.
</li><li>Try <code>abs_integrate_use_if</code>, and see if the result matches the first one. If it does, ignore it. Otherwise, emit a warning and return the answer.
</li></ol>
TicketMichael OrlitzkySun, 08 Mar 2015 19:09:07 GMT
https://trac.sagemath.org/ticket/12731#comment:24
https://trac.sagemath.org/ticket/12731#comment:24
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12731#comment:23" title="Comment 23">mjo</a>:
</p>
<blockquote class="citation">
<ol><li>Try the standard Maxima <code>integrate</code>, and save the result.
</li><li>Try <code>signum_int</code>, and see if the result matches the first one. If it does, ignore it. Otherwise, emit a warning and return the answer.
</li><li>Try <code>abs_integrate_use_if</code>, and see if the result matches the first one. If it does, ignore it. Otherwise, emit a warning and return the answer.
</li></ol></blockquote>
<p>
<br />
Oh, and if <code>integrate</code> works, we can skip steps 2 and 3.
</p>
TicketNils BruinMon, 09 Mar 2015 01:54:18 GMT
https://trac.sagemath.org/ticket/12731#comment:25
https://trac.sagemath.org/ticket/12731#comment:25
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12731#comment:23" title="Comment 23">mjo</a>:
</p>
<blockquote class="citation">
<p>
If we set this variable to the empty list, then no additional integrations will be attempted by Maxima (by default). But, we can still try them ourselves. So we could,
</p>
<ol><li>Try the standard Maxima <code>integrate</code>, and save the result.
</li><li>Try <code>signum_int</code>, and see if the result matches the first one. If it does, ignore it. Otherwise, emit a warning and return the answer.
</li><li>Try <code>abs_integrate_use_if</code>, and see if the result matches the first one. If it does, ignore it. Otherwise, emit a warning and return the answer.
</li></ol></blockquote>
<p>
That's an excellent find and it allows us to have much finer grained control over what integration methods should be tried. However, I'm not so sure that "printing a warning" is the right solution. There's a problem with stopgap messages in general:
</p>
<ul><li>they just get printed. They can easily get lost if a lot of other output gets printed.
</li><li>they only get printed once. We're dealing here with an issue that only applies to certain integrals. We assume you're OK as long as the message is printed. When you run into the message, then the result you're looking at at that moment is suspect. After that one, the message doesn't get printed anymore, so you should consider all subsequent results suspect. However, since the behaviour is much more similar to the pre-message situation, it's easy to think that fresh computations in the same session are NOT suspect.
</li></ul><p>
I think it is better to simply NOT try the suspect integration methods upon a normal integral invocation and only resort to them when a special command/flag is given, e.g.:
</p>
<pre class="wiki">sage: integrate(abs(sin(x)),x,0,pi)
integrate(abs(sin(x)), x, 0, pi)
sage: integrate(abs(sin(x)),x,0,pi, algorithm="spaced_out_maxima")
0
</pre><p>
or whatever access method we want to use (and whatever result we get from that).
</p>
<p>
In any case, we also need to clear <code>extra_definite_integration_methods</code>.
</p>
TicketKarl-Dieter CrismanMon, 09 Mar 2015 23:19:20 GMT
https://trac.sagemath.org/ticket/12731#comment:26
https://trac.sagemath.org/ticket/12731#comment:26
<blockquote class="citation">
<blockquote class="citation">
<p>
If we set this variable to the empty list, then no additional integrations will be attempted by Maxima (by default). But, we can still try them ourselves. So we could,
</p>
<ol><li>Try the standard Maxima <code>integrate</code>, and save the result.
</li><li>Try <code>signum_int</code>, and see if the result matches the first one. If it does, ignore it. Otherwise, emit a warning and return the answer.
</li><li>Try <code>abs_integrate_use_if</code>, and see if the result matches the first one. If it does, ignore it. Otherwise, emit a warning and return the answer.
</li></ol></blockquote>
<p>
That's an excellent find and it allows us to have much finer grained control over what integration methods should be tried. However, I'm not so sure that "printing a warning" is the right solution. There's a problem with stopgap messages in general:
</p>
<ul><li>they just get printed. They can easily get lost if a lot of other output gets printed.
</li><li>they only get printed once. We're dealing here with an issue that only applies to certain integrals. We assume you're OK as long as the message is printed. When you run into the message, then the result you're looking at at that moment is suspect. After that one, the message doesn't get printed anymore, so you should consider all subsequent results suspect. However, since the behaviour is much more similar to the pre-message situation, it's easy to think that fresh computations in the same session are NOT suspect.
</li></ul><p>
I think it is better to simply NOT try the suspect integration methods upon a normal integral invocation and only resort to them when a special command/flag is given, e.g.:
</p>
<pre class="wiki">sage: integrate(abs(sin(x)),x,0,pi)
integrate(abs(sin(x)), x, 0, pi)
sage: integrate(abs(sin(x)),x,0,pi, algorithm="spaced_out_maxima")
0
</pre><p>
or whatever access method we want to use (and whatever result we get from that).
</p>
</blockquote>
<p>
+1
</p>
TicketJulien PuydtSun, 15 Mar 2015 20:37:59 GMT
https://trac.sagemath.org/ticket/12731#comment:27
https://trac.sagemath.org/ticket/12731#comment:27
<p>
Is that ticket really needs_review ? The last comments point to a needs_work.
</p>
<p>
And notice that a needs_review ticket with no author won't suit Volker :-P
</p>
TicketRalf StephanMon, 16 Mar 2015 07:39:24 GMTauthor set
https://trac.sagemath.org/ticket/12731#comment:28
https://trac.sagemath.org/ticket/12731#comment:28
<ul>
<li><strong>author</strong>
set to <em>Ralf Stephan</em>
</li>
</ul>
TicketFrédéric ChapotonTue, 24 Mar 2015 20:30:15 GMTstatus changed
https://trac.sagemath.org/ticket/12731#comment:29
https://trac.sagemath.org/ticket/12731#comment:29
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
One failing doctest:
</p>
<pre class="wiki">File "src/sage/functions/piecewise.py", line 811, in sage.functions.piecewise.PiecewisePolynomial.integral
Failed example:
f.integral()
Expected:
Piecewise defined function with 1 parts, [[(-Infinity, +Infinity), x |--> -1/2*((sgn(x) - 1)*e^(2*x) - 2*e^x*sgn(x) + sgn(x) + 1)*e^(-x) - 1]]
Got:
Piecewise defined function with 1 parts, [[(-Infinity, +Infinity), x |--> -integrate(e^(-abs(x)), x, x, +Infinity)]]
</pre>
TicketKarl-Dieter CrismanMon, 13 Apr 2015 18:39:26 GMT
https://trac.sagemath.org/ticket/12731#comment:30
https://trac.sagemath.org/ticket/12731#comment:30
<p>
Related? <a class="ext-link" href="http://ask.sagemath.org/question/26516/wrong-answer-for-integral/"><span class="icon"></span>This question.</a>
</p>
TicketgitWed, 17 Jun 2015 15:17:24 GMTcommit changed
https://trac.sagemath.org/ticket/12731#comment:31
https://trac.sagemath.org/ticket/12731#comment:31
<ul>
<li><strong>commit</strong>
changed from <em>4790fc753098c35bbd5d2580b77f77ac511f3fdd</em> to <em>1993a28f9ea2dec2cfb255fddee6f01939f69372</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=2ea38b19d4aeeb31fa11b6d5cf6d4353e0b5def4"><span class="icon"></span>2ea38b1</a></td><td><code>Merge branch 'develop' into t/12731/disable_abs_integrate</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=1993a28f9ea2dec2cfb255fddee6f01939f69372"><span class="icon"></span>1993a28</a></td><td><code>12731: remove doctest dependent on abs_integrate</code>
</td></tr></table>
TicketRalf StephanWed, 17 Jun 2015 15:18:05 GMTstatus, milestone changed
https://trac.sagemath.org/ticket/12731#comment:32
https://trac.sagemath.org/ticket/12731#comment:32
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage-6.6</em> to <em>sage-6.8</em>
</li>
</ul>
TicketKarl-Dieter CrismanWed, 17 Jun 2015 15:48:06 GMT
https://trac.sagemath.org/ticket/12731#comment:33
https://trac.sagemath.org/ticket/12731#comment:33
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12731#comment:26" title="Comment 26">kcrisman</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<blockquote class="citation">
<p>
If we set this variable to the empty list, then no additional integrations will be attempted by Maxima (by default). But, we can still try them ourselves. So we could,
</p>
<ol><li>Try the standard Maxima <code>integrate</code>, and save the result.
</li><li>Try <code>signum_int</code>, and see if the result matches the first one. If it does, ignore it. Otherwise, emit a warning and return the answer.
</li><li>Try <code>abs_integrate_use_if</code>, and see if the result matches the first one. If it does, ignore it. Otherwise, emit a warning and return the answer.
</li></ol></blockquote>
</blockquote>
</blockquote>
<p>
It won't, because it will always return something like this:
</p>
<pre class="wiki">sage: integrate(1/(1 + abs(x+1) + abs(x-1)),x)
TypeError: unable to make sense of Maxima expression 'if(-(_SAGE_VAR_x+1)>0,-log(1-2*_SAGE_VAR_x)/2+log(3)-2/3,if(-(_SAGE_VAR_x-1)>0,_SAGE_VAR_x/3+log(3)/2-1/3,log(2*_SAGE_VAR_x+1)/2))' in Sage
</pre><blockquote class="citation">
<blockquote class="citation">
<p>
I think it is better to simply NOT try the suspect integration methods upon a normal integral invocation and only resort to them when a special command/flag is given, e.g.:
</p>
<pre class="wiki">sage: integrate(abs(sin(x)),x,0,pi)
integrate(abs(sin(x)), x, 0, pi)
sage: integrate(abs(sin(x)),x,0,pi, algorithm="spaced_out_maxima")
0
</pre><p>
or whatever access method we want to use (and whatever result we get from that).
</p>
</blockquote>
<p>
+1
</p>
</blockquote>
<p>
I would be in favor of this, and would give positive review to changes disabling by default but allowing this. I think it would be pretty easy to implement, in fact.
</p>
<ul><li>Keep <code>abs_integrate</code> loading initially in <code>maxima_lib.py</code>.
</li><li>Immediately set the two <code>methods</code> to <code>[]</code>, perhaps right with <code>init_code.append('nolabels : true')</code> a few lines later.
</li><li>Then add an integrator in <code>src/sage/symbolic/integration/external.py</code>, something like
<pre class="wiki">def maxima_absint_integrator(expression, v, a=None, b=None):
from sage.calculus.calculus import maxima
maxima.eval("extra_definite_integration_methods=['abs_defint]")
maxima.eval("extra_integration_methods=['signum_int]") # NOT using the if variant
if not isinstance(expression, Expression):
expression = SR(expression)
if a is None:
result = maxima.sr_integral(expression,v)
else:
result = maxima.sr_integral(expression, v, a, b)
maxima.eval("extra_definite_integration_methods=[]")
maxima.eval("extra_integration_methods=[]") # NOT using the if variant
return result._sage_()
</pre></li><li>Then in <code>src/sage/symbolic/integration/integral.py</code> just add
<pre class="wiki">import sage.symbolic.integration.external as external
available_integrators['maxima'] = external.maxima_integrator
available_integrators['maxima_absint'] = external.maxima_absint_integrator
available_integrators['sympy'] = external.sympy_integrator
available_integrators['mathematica_free'] = external.mma_free_integrator
available_integrators['fricas'] = external.fricas_integrator
</pre>and port doctests, with a humongous warning not to use this unless you are willing to check answers numerically or something.
</li></ul><p>
That could, in principle, be a separate ticket, but I would want them to depend upon each other. Also, that wouldn't remove the necessity of <a class="new ticket" href="https://trac.sagemath.org/ticket/17910" title="#17910: task: unsolved piecewise integrals metaticket (new)">#17910</a>.
</p>
<p>
By the way, it's interesting that <a class="ext-link" href="http://sourceforge.net/p/maxima/bugs/2242/#8ddc"><span class="icon"></span>http://sourceforge.net/p/maxima/bugs/2242/#8ddc</a> suggests that adding <code>'integrate</code> to the methods lists could actually do at least some of these integrals...
</p>
TicketJeroen DemeyerWed, 17 Jun 2015 16:57:45 GMTstatus changed
https://trac.sagemath.org/ticket/12731#comment:34
https://trac.sagemath.org/ticket/12731#comment:34
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Never <em>remove</em> doctests, mark them as <code># known bug (Trac #17910)</code>.
</p>
TicketSamuel LelièvreThu, 29 Oct 2015 07:57:17 GMTdescription changed
https://trac.sagemath.org/ticket/12731#comment:35
https://trac.sagemath.org/ticket/12731#comment:35
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/12731?action=diff&version=35">diff</a>)
</li>
</ul>
TicketPaul MassonThu, 28 Jul 2016 20:50:01 GMTcc changed
https://trac.sagemath.org/ticket/12731#comment:36
https://trac.sagemath.org/ticket/12731#comment:36
<ul>
<li><strong>cc</strong>
<em>Paul Masson</em> added
</li>
</ul>
TicketRalf StephanSun, 26 Nov 2017 07:16:44 GMTdescription changed
https://trac.sagemath.org/ticket/12731#comment:37
https://trac.sagemath.org/ticket/12731#comment:37
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/12731?action=diff&version=37">diff</a>)
</li>
</ul>
TicketMarcelo ForetsMon, 27 Nov 2017 12:49:22 GMTcc changed
https://trac.sagemath.org/ticket/12731#comment:38
https://trac.sagemath.org/ticket/12731#comment:38
<ul>
<li><strong>cc</strong>
<em>Marcelo Forets</em> added
</li>
</ul>
TicketAntonio RojasWed, 24 Apr 2019 17:27:02 GMTdescription changed
https://trac.sagemath.org/ticket/12731#comment:39
https://trac.sagemath.org/ticket/12731#comment:39
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/12731?action=diff&version=39">diff</a>)
</li>
</ul>
TicketFrédéric ChapotonWed, 24 Apr 2019 19:23:49 GMTcommit, branch changed
https://trac.sagemath.org/ticket/12731#comment:40
https://trac.sagemath.org/ticket/12731#comment:40
<ul>
<li><strong>commit</strong>
changed from <em>1993a28f9ea2dec2cfb255fddee6f01939f69372</em> to <em>209b2c86c77c9069b38f436331d683720a2faeec</em>
</li>
<li><strong>branch</strong>
changed from <em>u/rws/disable_abs_integrate</em> to <em>public/disable_abs_integrate</em>
</li>
</ul>
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=209b2c86c77c9069b38f436331d683720a2faeec"><span class="icon"></span>209b2c8</a></td><td><code>Merge branch 'u/rws/disable_abs_integrate' in 8.8.b3</code>
</td></tr></table>
TicketFrédéric ChapotonWed, 24 Apr 2019 19:32:42 GMTcommit, branch changed
https://trac.sagemath.org/ticket/12731#comment:41
https://trac.sagemath.org/ticket/12731#comment:41
<ul>
<li><strong>commit</strong>
changed from <em>209b2c86c77c9069b38f436331d683720a2faeec</em> to <em>1993a28f9ea2dec2cfb255fddee6f01939f69372</em>
</li>
<li><strong>branch</strong>
changed from <em>public/disable_abs_integrate</em> to <em>u/rws/disable_abs_integrate</em>
</li>
</ul>
<p>
my merge was incorrect, so undone
</p>
TicketFrédéric ChapotonFri, 17 May 2019 17:52:58 GMTkeywords set
https://trac.sagemath.org/ticket/12731#comment:42
https://trac.sagemath.org/ticket/12731#comment:42
<ul>
<li><strong>keywords</strong>
<em>abs_integrate</em> added
</li>
</ul>
TicketFrédéric ChapotonFri, 17 May 2019 18:29:52 GMTstatus, commit, branch, milestone changed
https://trac.sagemath.org/ticket/12731#comment:43
https://trac.sagemath.org/ticket/12731#comment:43
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>commit</strong>
changed from <em>1993a28f9ea2dec2cfb255fddee6f01939f69372</em> to <em>b5c9cc58cdda15c3d33e5a47ed953bd17989a6c2</em>
</li>
<li><strong>branch</strong>
changed from <em>u/rws/disable_abs_integrate</em> to <em>u/chapoton/12731</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage-6.8</em> to <em>sage-8.8</em>
</li>
</ul>
<p>
Here is a fresh new branch
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="https://git.sagemath.org/sage.git/commit?id=b5c9cc58cdda15c3d33e5a47ed953bd17989a6c2"><span class="icon"></span>b5c9cc5</a></td><td><code>disable abs_integrate buggy module of maxima</code>
</td></tr></table>
TicketKarl-Dieter CrismanFri, 17 May 2019 19:06:17 GMT
https://trac.sagemath.org/ticket/12731#comment:44
https://trac.sagemath.org/ticket/12731#comment:44
<p>
Thanks - I wish there was a better fix than disabling. Can you briefly comment on
</p>
<ul><li>The removal of the radexpand example
</li><li>the <code>known bug</code> ones
</li></ul><p>
I'm sure they are quite logical but a quick glance fails to reveal it, as opposed to where you put the unevaluated integral in to replace the <code>abs_integrate</code> behavior.
</p>
<p>
Or maybe this was already present behavior and you really did just refresh this, in which case no worries. It seems like <a class="ticket" href="https://trac.sagemath.org/ticket/12731#comment:33" title="Comment 33">comment:33</a> was the last substantive part of the discussion and memory fails.
</p>
TicketFrédéric ChapotonFri, 17 May 2019 19:50:25 GMT
https://trac.sagemath.org/ticket/12731#comment:45
https://trac.sagemath.org/ticket/12731#comment:45
<p>
Tagging by <code>known bug</code> allows to remember that one could hope for the answer displayed. I think Jeroen suggested to keep the doctest in this way, rather than remove them.
</p>
<p>
And the <code>radexpand</code> example no longer works without <code>abs_integrate</code>, just returning unevaluated.
</p>
TicketFrédéric ChapotonSat, 18 May 2019 13:39:42 GMT
https://trac.sagemath.org/ticket/12731#comment:46
https://trac.sagemath.org/ticket/12731#comment:46
<p>
bot is morally green, please review
</p>
TicketDima PasechnikWed, 22 May 2019 08:21:57 GMTstatus changed; reviewer set
https://trac.sagemath.org/ticket/12731#comment:47
https://trac.sagemath.org/ticket/12731#comment:47
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
set to <em>Dima Pasechnik</em>
</li>
</ul>
<p>
looks good to me. Please add yourself as authors/reviewers...
</p>
TicketFrédéric ChapotonWed, 22 May 2019 08:22:57 GMTauthor changed
https://trac.sagemath.org/ticket/12731#comment:48
https://trac.sagemath.org/ticket/12731#comment:48
<ul>
<li><strong>author</strong>
changed from <em>Ralf Stephan</em> to <em>Ralf Stephan, Frédéric Chapoton</em>
</li>
</ul>
TicketVolker BraunFri, 24 May 2019 18:29:59 GMTstatus, branch changed; resolution set
https://trac.sagemath.org/ticket/12731#comment:49
https://trac.sagemath.org/ticket/12731#comment:49
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>branch</strong>
changed from <em>u/chapoton/12731</em> to <em>b5c9cc58cdda15c3d33e5a47ed953bd17989a6c2</em>
</li>
</ul>
TicketKarl-Dieter CrismanFri, 28 Jun 2019 01:05:24 GMTcommit deleted
https://trac.sagemath.org/ticket/12731#comment:50
https://trac.sagemath.org/ticket/12731#comment:50
<ul>
<li><strong>commit</strong>
<em>b5c9cc58cdda15c3d33e5a47ed953bd17989a6c2</em> deleted
</li>
</ul>
<p>
At least according to github, the following stuff in <code>sage/maxima_lib.py</code> was not removed (probably because it still passes doctests as Maxima proper improved in the meantime):
</p>
<pre class="wiki"> Make sure the abs_integrate package is being used,
:trac:`11483`. The following are examples from the Maxima
abs_integrate documentation::
sage: integrate(abs(x), x)
1/2*x*abs(x)
</pre>
TicketErik BrayWed, 03 Jul 2019 11:34:48 GMTmilestone changed
https://trac.sagemath.org/ticket/12731#comment:51
https://trac.sagemath.org/ticket/12731#comment:51
<ul>
<li><strong>milestone</strong>
changed from <em>sage-8.8</em> to <em>sage-8.9</em>
</li>
</ul>
<p>
Not in Sage 8.8. Let's please to try keep tickets' milestones related to the release in which we actually intend to include them, and in particular the release in which they were <em>actually</em> included, especially when closing tickets.
</p>
Ticket