I have not used this myself, but help says it depends on number of terms if it can work or not:

Help also says Similar functionality is provided by gfun[`listtorec`]

May be you can try that and see.

@Alfred_F 

Is there a command for integration by parts? 

There is one in IntegrationTools package

https://www.maplesoft.com/support/help/Maple/view.aspx?path=IntegrationTools/Parts

there is a numerical pde cheat sheet here which gives some common schemes. Another is this  and this  but none has any Maple code.

There are examples here of 1,2,3D heat pde's with Maple code for each. but not numerical, only analytical.

@janhardo 

Your expectation that the ODE output always uses set notation is probably not always possible.

Why?  This is how Mathematica does it. It always give solution(s) as list of lists. Even for one solution.

The difference in Maple, it has both set {} and list []. In Mathematica there is only list {}.  This makes it easier in some sense.

But Maple output could have standardize on outputing using one of these (either set or list), regadless of the input.  Some examples:

You see above, solution is always list of lists. 

Standard form of result makes it much easier to process than having different output for different cases. 

btw, this issue does not just apply to dsolve.  solve() also have same problem. different output  is given depending on input.   There is no standard.

I do not expect Maplesoft to change these things now, too late as this will break current code.

But these issues should have been more carefully thought about 45 years ago when Maple started.

@sand15 

How would you write this boundary conditions in Maple if not y(infinity)=value? 

Ofcourse in non computer setting, you are right, that we always mean limit as x->infinity then y=value. 

Many books write y(infinity)=value. 

In Maple the code and the boundary conditions become

ode:=diff(y(x),x$2)-y(x)=0;
IC:= y(0)=1,y(infinity)=0;
sol:=dsolve([ode,IC])

odetest(sol,[ode,IC])

I am here talking about using a CAS to solve an ode. Not about how one would write things for a math paper

If I write this in Maple

ode:=diff(y(x),x$2)-y(x)=0;
IC:= y(0)=1,limit(y(x),x=infinity)=0;
sol:=dsolve([ode,IC])

Then Maple gives error

The problem in the original question was from a book also, I did not make it up. But I can't use limit as the book shows. so had to write y(infinity)=value.

The question is, if Maple should have returned a solution which do not verify using its own odetest command or if it would be better not to return any solution.

@C_R 

"Simplicity is the ultimate sophistication." this is true.

Fyi, both results with sqrt(2) in numerator vs. just 2 in numerator have same leaf count

B:=sqrt(2)/( sqrt(2+(-1-x)*b^2)*sqrt((1-b^2)));
C:=2/( sqrt(1-b^2)*sqrt(4-2*b^2-2*b^2*x));

MmaTranslator:-Mma:-LeafCount(B);
MmaTranslator:-Mma:-LeafCount(C);

Both give 26.  So both of these are "equally" simple using leafcount as measure.

In Maple

A := (sqrt(x + 1)*sqrt(-2*b^2*x - 2*b^2 + 4)*
    sqrt(-(x + 1)*(b^2 - 1)))/((b^2*x + b^2 - 2)*(b^2*x + b^2 - x - 1));
simplify(A) assuming x>-1;

Leaf count of the above is 34.

In Mathematica, Simplify with assumption x>-1 gives the result you wanted (with the version having sqrt(2) in numerator, but this has same leafcount as the other version) 

Maple should try to improve its simplify(). I suggested before that Maple should have new separate command called full_simplify() if they do not want to change simplify for backword compatibility.

simplify() is one the core commands for any CAS system, along with timelimit().  May be Maplesoft can use AI to write the new command full_simplify().

@acer 

I've been using map myself for this sort of thing for sometime

L := [a = b, c = c, d = e, f = f,z, sin(x)=1];
map(X->`if`(X::`=` and evalb(X),NULL,X),L)

I have not found a case where it failed so far to remove any A=A type solutions. If you find one please let me know so I can change my code.

You have 7 equations and trying to solve for 4 variables. This is overdetermined system. Most such systems do not have solution unless there is linear relation between the equations. (say one eq. is multiple of another) to make the extra ones redundant.

Sometimes adding a variable or two makes it possible to solve the system, even though it is still overdetermined, depending on which variable you add. You can read more about why this can happen sometimes.  But you should not be trying to solve using more equations than variables as a general rule. 

You have 14 variables in your equations, Instead of solving for {omega, a[0],a[1],b[1]}, if you solve for {omega, a[0],a[1],b[1],mu} then if finds solution. Also if you solve for {omega, a[0],a[1],b[1],alpha} 

solve(eqs, {omega, a[0],a[1],b[1],alpha});

solve(eqs, {omega, a[0],a[1],b[1],mu});

btw, on side remark, you should avoid using b and b[0] in same code. They share base name and this can cause problem. see what happens

If you want, use b__0 and not b[0] as b__0 do not share the base name with b so safe to mix:

@Alfred_F 

how is a grid polygon drawn with pinpoint precision?

if you mean you want lines drawn between each pair of points and not one long line across, then an option is to use plottools:-line, something like

restart;

max_X:=8: max_Y:=5:
grid_points:= [seq(seq([n,m],n=0..max_X),m=0..max_Y)]:

H_lines := ListTools:-Flatten(map(Y->map(X->plottools:-line([X,Y],[X+1,Y]),[$0..max_X-1]),[$0..max_Y])):

V_lines := ListTools:-Flatten(map(Y->map(X->plottools:-line([X,Y],[X,Y+1]),[$0..max_X]),[$0..max_Y-1])):

the_points := plots:-pointplot(grid_points, symbol=circle, symbolsize=12, color=red):

plots:-display(the_points, H_lines , V_lines, view=[0..max_X, 0..max_Y],scaling=constrained);

Why this question marked "Incomplete question" ?

@acer 

You are right, they give different solution. I did not notice that, but for the context this is used in, both are actually valid.

This is supposed to be solution to differential equation and the program verifies always using odetest the resulting solution with odetest. If solution do not validate, it is rejected and tries next case.

Both solutions in this case give the same exact result from odetest, they satisfy the IC and the ode except at t=0 or t=Pi.

Same as Maple own solution.

But even little better. Maple own solution do not satisfy both IC's, only one of them.

So yes, result is different, but both are correct for the purpose of being solution to this differential equation because both give the same exact output from odetest.

Here is worksheet showing this.

Download limit_problem_april_2_2026_V2.mw

@Alfred_F 

OK, but the IC is at infinity? You changed y(infinity)=Pi to y(u)=Pi.  I am not sure the teacher will accept this.  How is y(u)=Pi the same as y(infinity)=Pi?    

This is from textbook

The book actually do not give solution for this in back. 

Both Mathematica and sympy could not solve this with IC  y(infinity)=Pi. But can solve it with no IC.

The difficulty here is the IC. I can solve this by hand without IC, but do not know how with the IC y(infinity)=Pi and do not know how Maple also handled the IC internally.

see also

https://mapleprimes.com/maplesoftblog/234338-Maple-2026-Is-Here#comment206652

@WD0HHU 

Fyi, to use Array like you did and streatch out each plot, there is a much simpler way, like this

s:=t->2*t^4-30*t^3+135*t^2-120*t-10:
v:=t->diff(s(t),t):
p1:=plot(s(t),t=0..8,'gridlines','thickness'=3,'color'="red",'title'="Plot of s(t)"):
p2:=plot(v(t),t=0..8,'gridlines','thickness'=3,'color'="blue",'title'="Plot of v(t)"):

# now use 

plots:-display(Array([p1,p2]),size=[0.5,0.5]); 

This gives similar to what you showed there