Similarly as Francis J. Wright, I encountered problems with the new version of dsolve in Rel.5: Consider the following example:
restart; f1:=a11*y1(x)+a12*y2(x)+b1(x); f2:=a21*y1(x)+a22*y2(x)+b2(x); odesys:={diff(y1(x),x)=f1,diff(y2(x),x)=f2,y1(0)=y1ini,y2(0)=y2ini}; dsolve(odesys,{y1(x),y2(x)});
Under Rel.4 this yields a correct representation of the solution of such a system. Evidently it does not work under Rel.5; the output contains strange things like integrals where the lower limit is the null string and the upper limit is 0. (?)
This bug is removed with the new ODEtools package of Maple V.5 (U. Klein)
I had no problem with R5. I did write f1:=x->etc and diff(y1(x),x)=f1(x). Used
Windows 95.
Some days ago, there was a question to the MUG about the representation changes of differential equations, but the expression was very great. At our university there occurred a similar problem with a much smaller expression:
The problem:
eq1:=(D@@2)(x)(t)+k^2*x(t)=f(t); (2) 2 eq1 := (D )(x)(t) + k x(t) = f(t) > i1:=x(0)=0; i1 := x(0) = 0 > i2:=D(x)(0)=0; i2 := D(x)(0) = 0
The representation of the result in Maple V Release 4:
dsolve({eq1,i1,i2},x(t)); / t | / | | x(t) = |- | sin(k u) f(u) du cos(k t) | | | / \ 0 t \ / | | | + | cos(k u) f(u) du sin(k t)|/k | | / | 0 /
but in Release 5 we get:
### WARNING: `dsolve` has been extensively rewritten, many new result forms can occur
and options are slightly different, see help page for details
> dsolve({eq1,i1,i2},x(t)); / | cos(k t) f(t) x(t) = | ------------- dt sin(k t) | k / / | sin(k t) f(t) + | - ------------- dt cos(k t) | k / 0 / | cos(k _a) f(_a) - | --------------- d_a sin(k t) | k / 0 / | sin(k _a) f(_a) + | --------------- d_a cos(k t) | k /
The question is now , how the different integrals have to be interpreted and why the representation was changed?
The answer by Maple R5 is correct. You can verify this using the new command odetest:
> dsolve(odesys,{y1(x),y2(x)}); # large output here... > odetest(%, remove(has,odesys,0)); {0}
Note that in Maple R5 there is a new command, intat, for representing integrals
"evaluated at a point" (see ?intat). Intats are typically useful to represent integrals
evaluated at a point which cannot be an integration variable.
The visual representation for intats (with an upper limit of integration representing the evaluation point) is not so unusual - see for instance: W.E. Boyce and R.C. Diprima, "Elementary Differential Equations and Boundary Value Problems", or at a more advanced level: G.W. Bluman and S. Kumei, Symmetries and Differential Equations, Applied Mathematical Sciences 81, Springer-Verlag (1989).
I agree however in that for boundary value problems, it would more interesting to have - by default - definite integrals instead of intats.
Possible solutions to your problem are:
1) by installing the ODEtools package, dsolve automatically avoids using intats in boundary value problems. For example, for your odesys, you receive an answer without intats, as in Maple R4. ODEtools is available at http://lie.uwaterloo.ca/odetools.html.
2) ODEtools also provides a small conversion routine, 'intat_to_int', which I’m pasting
below. This routine converts intats found in a given expression into "equivalent" (up to an
integration constant) definite integrals as follows:
> intat(f(x),x=a); a / | | f(x) dx | / > intat_to_int(%) = intat_to_int(%, definite); a / / | | | f(a) da = | f(x) dx | | / / 0
Note that when converting an intat into a definite integral, the resulting expression will be different from the original one by an integration constant (the integral evaluated at "0").
Here are the two subroutines conforming the intat_to_int command.
intat_to_int := proc(expr) local ans, extra, ii, zz; if has(expr,['intat,Intat,Int']) then zz := sort([op(indets(expr,{'intat,Intat,Int'}))], (a,b) -> not has(a,b)); if zz = [] then expr else ans := expr; if nargs > 1 then if nargs > 2 then ERROR(`Too many arguments; expected only two arguments`); elif args[2] <> 'definite' then ERROR(`Expected second argument to be 'definite', received`,args[2]) else extra := 1 fi; else extra := NULL; fi; to nops(zz) do ii := zz[1]=`intat_to_int/do`(zz[1],extra); zz := subs(ii,subsop(1=NULL,zz)); ans := subs(ii,ans); od; fi; else expr fi; end: `intat_to_int/do` := proc(II) local dx_at_t, integrand, t, x; if op(0,II)='Int' then int(op(II)) else # it is an intat or Intat # determine the integrand and the new integration variable dx integrand := op(1,II); dx_at_t := op(2,II); x := lhs(dx_at_t); t := rhs(dx_at_t); if nargs = 1 and x <> '_Z' and type(t,'name') and t <> '_Z' and not has(integrand,t) then int(subs(dx_at_t,integrand), t); elif t = 0 then int(integrand, x=`PDEtools/_C`(II)..t); else int(integrand, x=0..t); fi; fi; end:
First some general comments on R5.
I have spent some time during the last month to convert my worksheets from R4 to R5. During that work I have discovered a lot of new errors in R5 (all these are reported to the Support), which was not present in R4. Fortunately the opposite is also true. Maplesoft should have spent much more time testing R5 before they released it. Despite the new fancy things in R5, it seems to me that R5 is much of a RUSH WORK and that is not to Maples credit. I have been told that Maple will correct some of the most serious errors in R5 in a new patch in the near future.
We intend to install R5 in our network before the next semester (term) and introduce R5 for all our students. But in lack of an updated R5, I think I prefer to continue using R4 in classes.
So to the unnessecary complicated solution of the following differential equation in R5 compared to R4. Please let me know if someone has a shorter way to end up with the R4 solution than I have made below.
R5 solution:
> ode:= r*diff(R(r),r)+r^2*diff(R(r),r$2) = lambda^2*R(r); / 2 \ /d \ 2 |d | 2 ode := r |-- R(r)| + r |--- R(r)| = lambda R(r) \dr / | 2 | \dr / >sol:=dsolve(ode1,R(r)); sol := R(r) = _C1 cosh(lambda ln(r)) + _C2 sinh(lambda ln(r))
This equation is uneccessary complicated for further use. To compare, the solution in R4 is:
solR4 := R(r) = _C1*r^lambda+_C2*r^(-lambda);
You have to manipulate the R5 solution sol to get the R4 solution, which I prefer for further use, for instance in this way:
> combine(convert(sol,exp)); R(r) = _C1 (1/2 exp(lambda ln(r)) + 1/2 exp(-lambda ln(r))) + _C2 (1/2 exp(lambda ln(r)) - 1/2 exp(-lambda ln(r))) > simplify(%); lambda (-lambda) lambda R(r) = 1/2 _C1 r + 1/2 _C1 r + 1/2 _C2 r (-lambda) - 1/2 _C2 r >subs(r^lambda=a,r^(-lambda)=b,sol2); R(r) = 1/2 _C1 a + 1/2 _C1 b + 1/2 _C2 a - 1/2 _C2 b > collect(%,[a,b]); R(r) = (1/2 _C1 + 1/2 _C2) a + (1/2 _C1 - 1/2 _C2) b >subs(a=r^lambda,b=r^(-lambda),op([2,1,1],%)=C1, op([2,2,1],%)=C2,%); lambda (-lambda) R(r) = C1 r + C2 r
Although the problem you are mentioning is not directly related to the ODEtools routines (dsolve R5 is based on ODEtools ’97), by installing the present version of ODEtools (http://lie.uwaterloo.ca/odetools.html), the answer to your linear ODE (actually an Euler ODE) is as straightforward as in R4:
> ode:= r*diff(R(r),r)+r^2*diff(R(r),r$2) = lambda^2*R(r); 2 2 ode := r R' + r R'' = lambda R > dsolve(ode); # Maple R5 with ODEtools lambda (-lambda) R = _C1 r + _C2 r
Use:
>simplify(convert(%,exp)); #This works.