Opened 3 years ago
Last modified 5 weeks ago
#14821 needs_work defect
Weird error in exponential integral
Reported by:  ppurka  Owned by:  burcin 

Priority:  minor  Milestone:  sage7.3 
Component:  calculus  Keywords:  
Cc:  nbruin, rws  Merged in:  
Authors:  Paul Masson  Reviewers:  Ralf Stephan 
Report Upstream:  N/A  Work issues:  
Branch:  u/paulmasson/14821 (Commits)  Commit:  65b3b55e4aa15b2bb85b3854611932e4d76637c7 
Dependencies:  Stopgaps: 
Description (last modified by )
integral(exp(300.0/(0.064*x+14.0)),x,0.0,120.0) ... RuntimeError: ECL says: In function GCD, the value of the second argument is 1.0 which is not of the expected type INTEGER
The original ticket description whose case does work now:
This is so trivial that I am surprised this bug even exists. :) Present since at least sage5.2 till present versions.
The following integral works
H = exp(x) H.integral(x, 0, 1) e^(1) + 1
But the following integral errors out
H = exp(1.0 * x) H.integral(x, 0, 1) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "_sage_input_19.py", line 10, in <module> exec compile(u'open("___code___.py","w").write("# * coding: utf8 *\\n" + _support_.preparse_worksheet_cell(base64.b64decode("SCA9IGV4cCgtMS4wKjEwXi0xKngpCkguaW50ZWdyYWwoeCwgMCwgMSk="),globals())+"\\n"); execfile(os.path.abspath("___code___.py")) File "", line 1, in <module> File "/tmp/tmpE7_LAK/___code___.py", line 4, in <module> exec compile(u'H.integral(x, _sage_const_0 , _sage_const_1 ) File "", line 1, in <module> File "expression.pyx", line 9058, in sage.symbolic.expression.Expression.integral (sage/symbolic/expression.cpp:37991) File "/usr/local/src/sage/sage5.2.server/local/lib/python2.7/sitepackages/sage/symbolic/integration/integral.py", line 683, in integrate return definite_integral(expression, v, a, b) File "function.pyx", line 432, in sage.symbolic.function.Function.__call__ (sage/symbolic/function.cpp:4941) File "/usr/local/src/sage/sage5.2.server/local/lib/python2.7/sitepackages/sage/symbolic/integration/integral.py", line 173, in _eval_ return integrator(*args) File "/usr/local/src/sage/sage5.2.server/local/lib/python2.7/sitepackages/sage/symbolic/integration/external.py", line 21, in maxima_integrator result = maxima.sr_integral(expression, v, a, b) File "/usr/local/src/sage/sage5.2.server/local/lib/python2.7/sitepackages/sage/interfaces/maxima_lib.py", line 746, in sr_integral raise error RuntimeError: ECL says: In function GCD, the value of the second argument is 1.0 which is not of the expected type INTEGER
Change History (13)
comment:1 Changed 3 years ago by
 Description modified (diff)
comment:2 Changed 3 years ago by
Almost certainly the same error (see this sagesupport thread:
sage: integral(exp(300.0/(0.064*x+14.0)),x,0.0,120.0)
and also this ask.sagemath question.
The real underlying issue is the one at this Maxima bug; basically, we use keepfloat:true
in Maxima so that things like the integral of e^(x^2)
come out right, but this causes things to go wrong in these examples.
And Nils' comment still applies, that it's not clear why something with a float in it should be integrated symbolically (rather than numerically) at all. I think this is an important point, though I'm not sure how to resolve it in such a ridiculously simple case as yours. Note that I updated the Maxima bug, and with keepfloat:false
it is ridiculously accurate as a float.
That said, we should still have a better error message, and ideally just a correct answer.
comment:3 Changed 3 years ago by

deleted dumb comment (look at the diff and comment:5 if you want to know why I deleted this :) 
I saw you mention in the ticket whether it is user error to provide a floating number 1.0
in the exponential function. The 1.0
used in the example is just an example. I had a more complicated number there. It really surprised me when the integral failed. Such kind of integrals should never fail.
comment:4 Changed 3 years ago by
 Cc nbruin added
Wait, I'm confused. What does the value of the derivative have to do with keepfloat
and this behavior?
sage: H = exp(.00001*x) sage: H.integral(x,0,1) <same error> sage: plot(H,(x,0,1),ymin=0) <essentially constant plot>
The reason why Nils and others consider this to be close to user error is that it's not clear what a nonnumerical integral of an integral with floats in it should mean. The indefinite integral would be inaccurate by definition. Or am I misrepresenting something, Nils?
One possible workaround I see is that we could catch this error and ask the user whether they wanted a numerical integral, or even return a numerical integral. We haven't seen this in circumstances without exponentials of floats.
Another thing to note is that it's the endpoints being floats which caused keepfloat
to be necessary. We could investigate whether we want to only use keepfloat:true
in those situations.
comment:5 Changed 3 years ago by
Oh, now that I read the maxima ticket again, I see that sage was forcing keepfloat true and not the other way around. Sorry for the misleading comments earlier.
comment:6 Changed 3 years ago by
 Milestone changed from sage6.1 to sage6.2
comment:7 Changed 2 years ago by
 Milestone changed from sage6.2 to sage6.3
comment:8 Changed 2 years ago by
 Milestone changed from sage6.3 to sage6.4
comment:9 Changed 20 months ago by
Original commands now give 0.6321205588285577
which seems correct so just a doctest is now needed.
comment:10 Changed 5 weeks ago by
 Branch set to u/paulmasson/14821
comment:11 Changed 5 weeks ago by
 Cc rws added
 Commit set to 65b3b55e4aa15b2bb85b3854611932e4d76637c7
 Milestone changed from sage6.4 to sage7.3
 Priority changed from major to minor
 Status changed from new to needs_review
comment:12 Changed 5 weeks ago by
comment:13 Changed 5 weeks ago by
 Description modified (diff)
 Reviewers set to Ralf Stephan
 Status changed from needs_review to needs_work
Your commit is fine and can be considered as reviewed. However, I made the mistake not looking at the second case given in comment:2. This one still crashes. So, to preserve the valuable discussion, instead of closing the ticket and opening a second, I put the second case on top of the ticket description and set "needs work".
Even simpler example.