7.49 BUG in dsolve in Maple V.4 (13.12.96)

7.49.1 Stanley J Houghton

This is a very much simpliﬁed version of a problem that indicates a bug in dsolve. I am running vn 4 on a Pentium PC under Windows 3.x

The simpliﬁed version makes it easier to understand.

> dsolve(diff(z(t),t) = int(y(u),u = 0 .. t), z(t));

z(t) = 1/2*y(u)*t^2+_C1

> diff(%,t);

diff(z(t),t) = y(u)*t



Certainly the integration variable 'u' should not appear anywhere in the result and, as shown above, if I diﬀerentiate the error is even more obvious.

The bug is removed with Maple V Release 5. (U. Klein)

7.49.2 Dan Dubois

Is any more information about $$y(u)$$ known? Maple is treating $$y(u)$$ as a constant when dsolve() is applied.

    |\^/|     Maple V Release 4
._|\|   |/|_. Copyright (c) 1981-1996 by Waterloo Maple Inc. All rights
\  MAPLE  /  reserved. Maple and Maple V are registered trademarks of
<____ ____>  Waterloo Maple Inc.
|       Type ? for help.

> dsolve(diff(z(t),t) = int(y(u),u = 0 .. t), z(t));

2
z(t) = 1/2 y(u) t  + _C1



If instead we were to use a variable a:

> dsolve(diff(z(t),t) = int(a,u = 0 .. t), z(t));

2
z(t) = 1/2 a t  + _C1



If however y(u) were deﬁned:

> y(u):=u^3;
3
y(u) := u

> dsolve(diff(z(t),t) = int(y(u),u = 0 .. t), z(t));

5
z(t) = 1/20 t  + _C1



I will however report this problem to our Math developers to investigate further.

7.49.3 Stanley J Houghton

I feel y(u) is clearly a funtion of a variable u and int(y(u),u=0..t) is clearly a function of t, although Maple certainly appears to be evaluating

     int(y(u),u=0..t)



incorrectly to

     y(u) * t



I think this is unreasonable and an error. Maple doesn’t evaluated the integral above wrongly in any other context. If the form of y is unknown, the integral should surely remain unevaluated. There is something wrong with Maple’s interpretation of int(y(u),u=0..t) in this context but I am not sure what.

While Stanley Houghton admits that his problem is a "very much simpliﬁed version" of the real problem of interest, I hope the following comments are of use.

Here is the original problem

> ODE1 := diff( z(t), t ) = Int( y(u), u=0..t );

t
/
d          |
ODE1 := -- z(t) =  |   y(u) du
dt         |
/
0



and the solution obtained using Release 4

> dsolve( ODE1, z(t) );

t
/
|                    2
z(t) = y(u) t  |   1 du - 1/2 y(u) t  + _C1
|
/
0



Note that the original problem can be written in a more traditional form by diﬀerentiating the equation

> ODE2 := diff( ODE1, t );

2
d
ODE2 := --- z(t) = y(t)
2
dt



Using the fact that D(y)(0)=0, Maple reports the solution:

> dsolve( { ODE2, D(z)(0)=0 }, z(t) );

t                t
/                /
|                |
z(t) = - |   u y(u) du +  |   y(u) du t + _C1
|                |
/                /
0                0



This is, presumably, closer to what Stan would like to see.

It would seem to me that dsolve could reasonably apply transformations that convert the input argument into a form that can be handled. Of course, I can see situations where these transformation would not be appropriate, or other problems might arise.

7.49.5 Joe Riel

As a workaround you can convert the integro-diﬀerential equation to a pure diﬀerential equation,

deq := diff(z(t),t) = int(y(u),u=0..t):
initcond := eval(subs(t=0, convert(deq,D))):
dsolve({initcond,diff(deq,t)},{z(t)});

t                t
/                /
|                |
z(t) = - |   u y(u) du +  |   y(u) du t + _C1
|                |
/                /
0                0

subs(%,deq): %;

t              t
/              /
|              |
|   y(u) du =  |   y(u) du
|              |
/              /
0              0



7.49.6 Stanley J Houghton

Many thanks for the suggestion. I can indeed apply your workround to the original problem and get the correct result.

I have also discovered that I get the same result if I use Laplace mode in dsolve and, again, the result is correct if I solve

    diff(z(t),t)=f(t)



and then evaluate the result after assigning

    f:=t->int(y(u),u=0..t);



However, the important issue is the way ’frontend’ handles functions of the form int(y(u),u=0..t) for it is in frontend (used within 'dsolve') that the misinterpretation occurs. It tries to freeze $$y(u)$$ independent of the second argument to int. As a result, the problem extends to other activities involving such functions.

This has been passed back to Maple who are considering it carefully. I am sure there are other ramiﬁcations.

7.49.7 Robert Israel

Stanley J Houghton wrote:

> dsolve(diff(z(t),t) = int(y(u),u = 0 .. t), z(t));

z(t) = 1/2*y(u)*t^2+_C1



Yes, certainly it’s a bug. I guess "dsolve" doesn’t expect unevaluated integrals in the equations.

As a workaround, I would use something like this:

> dsolve(diff(z(t),t) = Y(t), z(t));

/
|
z(t) =  |  Y(t) dt + _C1
|
/

> subs(Y(t)=int(y(u),u=0..t), %);

t
/   /
|   |
z(t) =  |   |  y(u) du dt + _C1
|   |
/   /
0

> diff(%,t);

t
/
d          |
---- z(t) =  |  y(u) du
dt          |
/
0