Opened 8 years ago

Closed 8 months ago

#14821 closed defect (fixed)

Weird error in exponential integral

Reported by: ppurka Owned by: burcin
Priority: minor Milestone: sage-9.3
Component: calculus Keywords: integration, maxima
Cc: nbruin, rws Merged in:
Authors: Paul Masson, Dave Morris Reviewers: Ralf Stephan, Travis Scrimshaw
Report Upstream: N/A Work issues:
Branch: 5101846 (Commits, GitHub, GitLab) Commit: 5101846c85fbd2064023db7ded02900d7ff2ab19
Dependencies: Stopgaps:

Status badges

Description (last modified by rws)

RuntimeError: ECL says: In function GCD, the value of the second argument is
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 sage-5.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 "", line 10, in <module>
    exec compile(u'open("","w").write("# -*- coding: utf-8 -*-\\n" + _support_.preparse_worksheet_cell(base64.b64decode("SCA9IGV4cCgtMS4wKjEwXi0xKngpCkguaW50ZWdyYWwoeCwgMCwgMSk="),globals())+"\\n"); execfile(os.path.abspath(""))
  File "", line 1, in <module>
  File "/tmp/tmpE7_LAK/", 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/sage-5.2.server/local/lib/python2.7/site-packages/sage/symbolic/integration/", 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/sage-5.2.server/local/lib/python2.7/site-packages/sage/symbolic/integration/", line 173, in _eval_
    return integrator(*args)
  File "/usr/local/src/sage/sage-5.2.server/local/lib/python2.7/site-packages/sage/symbolic/integration/", line 21, in maxima_integrator
    result = maxima.sr_integral(expression, v, a, b)
  File "/usr/local/src/sage/sage-5.2.server/local/lib/python2.7/site-packages/sage/interfaces/", line 746, in sr_integral
    raise error
RuntimeError: ECL says: In function GCD, the value of the second argument is
which is not of the expected type INTEGER

Change History (19)

comment:1 Changed 8 years ago by ppurka

  • Description modified (diff)

Even simpler example.

comment:2 Changed 8 years ago by kcrisman

Almost certainly the same error (see this sage-support 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 8 years ago by ppurka

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

Last edited 8 years ago by ppurka (previous) (diff)

comment:4 Changed 8 years ago by kcrisman

  • 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 non-numerical 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 8 years ago by ppurka

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 8 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:7 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:8 Changed 7 years ago by vbraun_spam

  • Milestone changed from sage-6.3 to sage-6.4

comment:9 Changed 7 years ago by rws

Original commands now give 0.6321205588285577 which seems correct so just a doctest is now needed.

comment:10 Changed 5 years ago by paulmasson

  • Branch set to u/paulmasson/14821

comment:11 Changed 5 years ago by paulmasson

  • Cc rws added
  • Commit set to 65b3b55e4aa15b2bb85b3854611932e4d76637c7
  • Milestone changed from sage-6.4 to sage-7.3
  • Priority changed from major to minor
  • Status changed from new to needs_review

Added doctest

New commits:

65b3b55Add doctest

comment:12 Changed 5 years ago by paulmasson

  • Authors set to Paul Masson

comment:13 Changed 5 years ago by rws

  • 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".

comment:14 Changed 3 years ago by gh-marcioadames

When running the following cell:

for n in [1..10]:

The output presents a sinus like curve with huge amplitude for t = 1.80, 1.79 or 1.78. This cannot be, for the exponential should make the values very small.

It seems to me a problem with the evaluation of the exponential for these values. What am I missing?

comment:15 Changed 9 months ago by gh-DaveWitteMorris

  • Branch changed from u/paulmasson/14821 to public/14821

comment:16 Changed 9 months ago by gh-DaveWitteMorris

  • Authors changed from Paul Masson to Paul Masson, Dave Morris
  • Commit changed from 65b3b55e4aa15b2bb85b3854611932e4d76637c7 to 5101846c85fbd2064023db7ded02900d7ff2ab19
  • Keywords integration maxima added
  • Milestone changed from sage-7.3 to sage-9.3
  • Status changed from needs_work to needs_review

The RuntimeError at the start of the ticket description (and mentioned in comment:13) is gone:

sage: integral(exp(-300.0/(-0.064*x+14.0)),x,0.0,120.0)                                        

I added a doctest for this and rebased on 9.3b5, so I hope we can close this old ticket.

The issue in comment:14 is invalid. The plot has an amplitude of approximately 0.12, which is correct. The only reason it looks large in the picture is that the y-axis has been scaled to fit the graph.

New commits:

758517aAdd doctest
5101846another doctest for trac 14821

comment:17 Changed 9 months ago by tscrim

  • Reviewers changed from Ralf Stephan to Ralf Stephan, Travis Scrimshaw
  • Status changed from needs_review to positive_review

I believe all issues raised in this ticket have been addressed.

comment:18 Changed 9 months ago by gh-DaveWitteMorris

Thanks for doing the review!

comment:19 Changed 8 months ago by vbraun

  • Branch changed from public/14821 to 5101846c85fbd2064023db7ded02900d7ff2ab19
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.