desolve failed to solve an ODE whose solution implies integration limits

[sagetrac-JGuzman]

When trying to solve a simple ODE whose rhs contains a function, Sage fails to interpret the Maxima output if this contains integration limits.

A minimal example

sage: x=var('x') # independent variable
sage: v=function('v', x) # dependent variable

if we now define a custom square pulse function

def pulse(tonset, tdur, amp):
    """
    returns a square pulse as a function of x, f(x) 
    the pulse is defined as follows:  
    t onset -- start of pulse  
    tdur   -- duration of pulse  
    amp    -- amplitude of pulse 
    """

    f(x)= amp*(sign(x-tonset)/2-sign(x-tonset-tdur)/2)
    return f

now we create a pulse function

sage: mypulse = pulse(tonset=5, tdur=5, amp=2)

and define differential equation

sage: dvdx = diff(v, x)-x -mypulse == 0 # mypulse(x) is function

To get the evolution of v we can use desolve

myvolt = desolve(de=dvdx, ivar=x, dvar=v, ics=[0,0])

The error message is:

TypeError: 
unable to make sense of Maxima expression 
'v(x)=-(2*(at(integrate(signum(x-5)-signum(x-13),x),[x=0,v(x)=0]))-2*int\egrate(signum(x-5)-signum(x-13),x)-x^2)/2' 
in Sage

desolve_laplace leads to similar error:

sage: desolve(de=dvdx, ivar=x, dvar=v, ics=[0,0])

TypeError: 
unable to make sense of Maxima expression 
'ilt(((laplace(signum(x-5),x,?g2733)-laplace(signum(x-13),x,?g2733)+v(0)\ )*?g2733^2+1)/?g2733^3,?g2733,x)' 
in Sage

According to Nils Bruin, the problem is that Maxima 'at' function. As described in Ticket #385, this can be a problem with the implementation of 'at' for SR.

Expressions that work

And adding the sign function to the differential function does not affect the solution.

sage: dvdx = diff(v, x)-v -sign(x) == 0 
sage: desolve(de=dvdx, ivar=x, dvar=v) 
sage: (c + integrate(e^(-x)*sgn(x), x))*e^x

However, adding initial conditions produces an output that Sage is not able to evaluate

sage: desolve(de = dvdx, ivar=x, dvar=v, ics=[0,0])

The output is:

TypeError: 
unable to make sense of Maxima expression 
'v(x)=e^x*integrate(e^-x*signum(x),x)-e^x*(at(integrate(e^-x*signum(x),x),[x=0,v(x)=0]))'
 in Sage

I guess Sage is not able to interpret the integrations limits prompted by Maxima (e.g [t=0,v(t)=0]).

Detailed information (and a more realistic example) can be found here: http://groups.google.com/group/sage-support/browse_thread/thread/8cc67d39510faca2

CC: @kcrisman @nbruin

Component: calculus

Keywords: maxima, at, desolve

Issue created by migration from https://trac.sagemath.org/ticket/11653

[sagetrac-JGuzman]

Changed keywords from none to maxima, at, desolve

[kcrisman]

comment:5

Thanks, Jose! Just a few pointers:

• You can use some formatting to do stuff here. There are links on the main Trac page, but the most useful one is putting code examples in triples { braces.
• The 'author' is the author of the patch. You are the reporter :) though perhaps also the eventual author as well!

[kcrisman]

Changed author from JGuzman to none

[kcrisman]

comment:6

As to the ticket, see the sage-support thread in question. The essential problem is that in laplace and taylor we take the answer from Maxima and send it to SR, which does parse the at correctly via the Maxima string thingie in calculus/calculus.py, but in the desolve_* functions we just coerce to .sage(), which does not. Probably changing this would fix it.

[sagetrac-JGuzman]

comment:7

I re-formatted the text according to kcrisman (thanks a lot for the suggestion!). I will have a look to the code soon. I am looking forward to implement it. If I understood correctly, the only thing to do is to make desolve_* take the answer from Maxima to SR.

[sagetrac-JGuzman]

comment:8

I changed the summary to delimit the error more carefully. Additional, a more detailed explanation is given of cases in which Sage is able to interpret Maxima output. I guess, the problem is that Sage is not able to interpret the integration limits prompted by the maxima expression.

[sagetrac-JGuzman]

comment:9

Change owner to burcin (I do not know why it changed last time !), and change the typesetting of TypeError

[kcrisman]

comment:12

There are several issues here, actually, so it may take a bit to solve this. We are apparently translating several things wrongly by not going through SR, but then there is also the 'general' variable ?g2733 which I remember being still undealt with... probably won't be fixed immediately :( just because of time constraints.