BUG in dsolve in Maple V.4 (13.12.96)

Stanley J Houghton

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

The simplified version makes it easier to understand.

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

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

Dan Dubois

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

If instead we were to use a variable a:

If however y(u) were defined:

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

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

incorrectly to

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.

Douglas B. Meade

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

Here is the original problem

and the solution obtained using Release 4

Note that the original problem can be written in a more traditional form by differentiating the equation

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

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.

Joe Riel

As a workaround you can convert the integro-differential equation to a pure differential equation,

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

and then evaluate the result after assigning

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

Robert Israel

Stanley J Houghton wrote:

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: