ECL says: In function GCD, the value of the second argument is not of the expected type INTEGER

[Bruno]

Hi,
I'm having problem with the code below,

var('x t'); k=1.38*(10**-23) ; e1=0 ; e2 =170*k ; na=6.02*(10**23)
a=0.1
assume(x>a)
u=1
n=1 + floor(u)

def DaRL(y,u):
    return (1/gamma(n-u))*diff(integral(y/((x-t)**(u-n+1)),t,a,x),x,n)

z=exp(-e1/(k*t)) + 3*exp(-e2/(k*t))
f=-t*k*log(z) 
s=-diff(f,t)

somat=sum( (((t-a)**k)/factorial(k))*((derivative(s,t,k)).limit(t=a)) for k in [0..(u-1)])

Dcaputo=DaRL((s-somat),u) ; Dcaputo

Which, in this case, is the same as

var('x t'); k=1.38*(10**-23) ; e1=0 ; e2 =170*k ; na=6.02*(10**23)

z=exp(-e1/(k*t)) + 3*exp(-e2/(k*t))
f=-t*k*log(z) 
s=-diff(f,t)

Dcaputo=Diff(s,t) ; Dcaputo , changing the variable 't' to 'x'. If we put s=sin(t);cos(t); t; 1; or any function with a known derivative it works.

But it's not working the way it should and I don't understand. When I ask Sage to do the code, Sage gives me this

Traceback (most recent call last):    def DaRL(y,u):
  File "", line 1, in <module>
    
  File "/tmp/tmpQtIbpd/___code___.py", line 18, in <module>
    exec compile(u'Dcaputo=DaRL((s-somat),u) ; Dcaputo
  File "", line 1, in <module>
    
  File "/tmp/tmpQtIbpd/___code___.py", line 10, in DaRL
    return (_sage_const_1 /gamma(n-u))*diff(integral(y/((x-t)**(u-n+_sage_const_1 )),t,a,x),x,n)
  File "/usr/lib/sagemath/local/lib/python2.7/site-packages/sage/misc/functional.py", line 740, in integral
    return x.integral(*args, **kwds)
  File "expression.pyx", line 9302, in sage.symbolic.expression.Expression.integral (sage/symbolic/expression.cpp:38413)
  File "/usr/lib/sagemath/local/lib/python2.7/site-packages/sage/symbolic/integration/integral.py", line 688, in integrate
    return definite_integral(expression, v, a, b)
  File "function.pyx", line 429, in sage.symbolic.function.Function.__call__ (sage/symbolic/function.cpp:5064)
  File "/usr/lib/sagemath/local/lib/python2.7/site-packages/sage/symbolic/integration/integral.py", line 173, in _eval_
    return integrator(*args)
  File "/usr/lib/sagemath/local/lib/python2.7/site-packages/sage/symbolic/integration/external.py", line 21, in maxima_integrator
    result = maxima.sr_integral(expression, v, a, b)
  File "/usr/lib/sagemath/local/lib/python2.7/site-packages/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

I don't know what this means. Can anyone give me a clue?

Thanks.

[Peter Bruin]

Hello,

This kind of problem has been reported before; see <http://trac.sagemath.org/ticket/14821>.

You could try the workaround

    sage: sage.calculus.calculus.maxima('keepfloat: false')

although this seems to be very slow (but maybe you expect it to be).

Peter

 

[Nils Bruin]

On Tuesday, June 3, 2014 7:12:12 AM UTC-7, Bruno wrote:

RuntimeError: ECL says: In function GCD, the value of the second argument is 1.0 which is not of the expected type INTEGER

I don't know what this means. Can anyone give me a clue?

It means Maxima, which gets used for integration, runs into a problem. This is because sage instructs maxima to keep floating point values rather than substitute them with rational or integer values. Apparently you are hitting a branch in the integration code that doesn't like that. A simpler example:

sage: integrate(e^(3.0/x),x,1,2)

RuntimeError: ECL says: In function GCD, the value of the second argument is
  1.0
which is not of the expected type INTEGER

In maxima proper we can get the same error, although by default things work (see below).

You may be able to hack sage's maxima into submission by executing:

sage: maxima_calculus.eval("keepfloat:false")

but I suspect you'll probably run into problems elsewhere.

---Example of same behaviour in maxima proper:

(%i2) integrate(%e^(3.0/x),x,1,2);

rat: replaced 3.0 by 3/1 = 3.0

rat: replaced -3.0 by -3/1 = -3.0

rat: replaced 3.0 by 3/1 = 3.0

rat: replaced 3.0 by 3/1 = 3.0

rat: replaced 20.085536923187668 by 138664461/6903697 = 20.08553692318768

rat: replaced 20.085536923187668 by 138664461/6903697 = 20.08553692318768

rat: replaced 20.085536923187668 by 138664461/6903697 = 20.08553692318768

rat: replaced 3.0 by 3/1 = 3.0

rat: replaced 3.0 by 3/1 = 3.0
                                                                   3
(%o2)     3 gamma_incomplete(- 1, - 3) - 3 gamma_incomplete(- 1, - -)
                                                                   2
(%i3) keepfloat:True;
(%o3)                                True
(%i4) integrate(%e^(3.0/x),x,1,2);

rat: replaced 3.0 by 3/1 = 3.0
Maxima encountered a Lisp error:

[Robert Dodier]

On 2014-06-03, Nils Bruin <nbr...@sfu.ca> wrote:

> It means Maxima, which gets used for integration, runs into a problem.
> This is because sage instructs maxima to keep floating point values
> rather than substitute them with rational or integer values. Apparently
> you are hitting a branch in the integration code that doesn't like that.

Agreed with this assessment. As for a workaround -- first thing to try
is to replace literal floats with symbols, and then substitute values
into the result. Second thing is to avoid floats by replacing them with
equivalent rational numbers, e.g., replace 6.02e-23 with 602*10^-25.

best

Robert Dodier

[Bruno]

Thank all for your attention and the explanation of the error message. I did replace the literal floats with symbols and it worked. 

--
You received this message because you are subscribed to a topic in the Google Groups "sage-support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-support/2NfVWrE4LA0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-support...@googlegroups.com.
To post to this group, send email to sage-s...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.