You can start by typing   

         ?dsolve

inside your maple workseet. There are examples there.

I do not know if there is a global option. But you could always do one of the following.

1. make just one of the numbers real by adding decimal at the end. (so instead of 9 write 9.0) This will pollute the rest of the computation where this number is used and causes all computation to be done as reals even if everything else is exact.
2. Do everything using exact numbers, and at the end just add evalf() on the result. (this should also be more accurate in general)

Why do you want Maple to automatically convert exact numbers to real numbers? What are you trying to do that can't be done by just calling evalf() on the final result?

@sursumCorda 

There is no need to have a fancy ode and expansion around infinity, Here are much simpler examples.

This has a regular singular point, but dsolve does not solve it (for good reason) when using series method.

ode := x^2 * diff(y(x),x$2) + x*diff(y(x),x) + x*y(x) = 1/x;
dsolve(ode,y(x),'series')

No solution. Because it needs asymptotic series due to the RHS nature, the particular solution can't be found using series method.

Here is another simpler example, same ode as above, but RHS is just one now.

ode := x^2* diff(y(x),x$2) + x*diff(y(x),x) + x*y(x) = 1;
dsolve(ode,y(x),'series')

Also no solution using series method. But can be solved using asymptotic series

The problem with these two examples is the same. Using series method, it is the particular solution which causes a problem. To see why, you have to work it by hand using Frobenius series. This is something all textbooks do not talk about. That is why if you open any textbook on differential equations and go to the power series section, you will not find any examples using inhomogeneous ode's to solve using Frobenius series.

All examples and problems given use ode with RHS is zero. 

May be because the authors do not know how to solve inhomogeneous ode's using Frobenius series, or if they do, they do not think it is important for some reason.

In all the books I have on odes' (over 100), I found only ONE such example from a very old textbook. That is why it is important to keep old math books. Many times they show things and methods that are lost and missing in the new and "modern" text books.

@sursumCorda 

Ah, I see. That is why I could not find it. that is good to know.

returns nothing, but Mma's AsymptoticDSolveValue can solve it. (I don't why.)

Because as I mentioned, AsymptoticDSolveValue internally picks the method needed. For an ordinary point of expansion,  it uses standard power series, and for a regular singular point it uses Frobenius series, and for an irregular singular point is uses asymptotic method, because power/ Frobenius series does not work on  irregular singular point.

Maple's dsolve command with series option only supports the first two type of points, but not the irregular singular point. That is why dsolve does not solve it.

The ode you have, the point t=0 is irregular singular point.

see Can-Maple-Solve-An-Ode-Using-Asymptotic

@sursumCorda 

Do you have a link to that Mathematica package you used? It does not seem to be part of Mathematica itself.

But you have used Asymptotic series expansion. I want the solution to be based on Frobenius series method. These are not the same. 

I know the Mathematica command I used is called AsymptoticDSolveValue also, but internally it will use Frobenius series to solve this as help says. I never liked the name AsymptoticDSolveValue because the user does not know if the series generated was done using standard power series method, or Frobenius series, or Asymptotic methods. Mathematica does not have separate command to do just standard power series solution for an ode, and separate command to solve an ode using asymptotic expansion method. They both live inside the same command AsymptoticDSolveValue.

But since what you show using Mathematica with this new package gives the same solution as what Maple shows using series method, may be then Maple internally used the asymptotic series and not  Frobenius series for this one special case?

i.e. Maple for this special case of the roots (the hard case, where one solution is not defined using power series), it used asymptotic series and not standard Frobenius series?

If this is the case,  then this will explain everything and why the result of Maple is different from the book only for this case. This explains also why both solutions are correct, but look different. They used different methods.

@vv 

When there are only two terms in the solution and two constants of integration, it is possible to do this and then rename things. I understand all of this. But the series solution has mutliple terms and only 2 constants of integrations. So I do not see how this could be possible in that case.

I tried to see if I can do this for the Maple solution by pulling part of the x^4 term from y_1 and move inside the y_2 term. But then the rest of the terms now gets missed up and I could not find a way to sort it out by playing the renaming trick. 

Anyway, here is my attempt. May be you can see a way with different manipulation. It seems Maple uses different algorithm to find this series solution than what the books give.

q3.pdf

@vv 

If both answers are correct, then how could one explain the difference in the actual series produced? For example for the ode

ode:=x*diff(y(x),x$2)-3*diff(y(x),x)+x*y(x)=0;

Which I showed in the first half of my question, by looking at the series generated, we see that Maple's answer is not the same as book. y_2 is missing an x^4 term and the coefficients are different.

How could two different looking series solutions to the same ode around the same point both be correct?

I located the bug, It is in the  inttrans:-invlaplace

it happens here. Compare

expr:=L*C*((L*C)^(1/2)*c[0]*s+(L*C)^(1/2)*c[1]+2*c[0])/(s^2*(L*C)^(1/2)*L*C+2*s*L*C+(L*C)^(1/2));
r1:=inttrans:-invlaplace(expr,s,x);

As a workaround, do partial fractions first, then it gives correct result because now invplace gives correct result on each simplified part of the partial fractions

expr_expanded := convert(expr,'fullparfrac',s);
r2:=map(X->inttrans:-invlaplace(X,s,x),expr_expanded );

We see the result is not the same

simplify(r1-r2)

@vs140580 

One way is

seq(`if`(L[i,1]="H",i,NULL),i=1..nops(L));
L_index:={%};
S:={{1,9},{1,20},{2,10},{3,4},{3,10},{3,14},{4,5},{4,6},
{5,7},{5,12},{6,8},{6,13},{7,9},{7,15},{8,9},{8,16},{10,11},
{11,17},{11,18},{11,19}}:

remove(has,S,L_index);

Lookup also select and selectremove

@Preben Alsholm 

Yes, wrapping it seems to be the key to making it work. So using nonunit and your wrapping trick seems to finally make it work. I still need to try more examples. This works

restart;
the_rule:=f(A::nonunit(anything))+f(B::nonunit(anything))=f(A)+1/2*f(B):
applyrule(the_rule,f(A)+f(B));
eval(%,f=(x->x)); 

But this hangs

restart;
the_rule:=A::nonunit(anything)+B::nonunit(anything)=A+1/2*B:
applyrule(the_rule,A+B);

So bottom line: use both nonunit and wrapping. but wrapping is not practical to use. Since the expression to be transformed is coming in without the terms having f() around them. So this will not really work in programming. It works for interactive usage where one can manually add f() around each symbol. 

So there is still problem with rules that does   A+B->A+1/2*B due to infinite applying of the rule. 

I looked at your ap function above, and I have no idea what your wrote. I see only 

ap:=proc (_rules, expr,count::nonnegint:=100)

But where is the body of the function?

So wrapping will not work for me to stop the infinite loop, and still need to figure how to your use your ap function, which so far, I do not know how as I do not see the definition of it,

@Carl Love 

Thanks. Using nonunit helps with applyrule. Yes. But I do not agree it is obvious. (else why no one mentioned its use before in this topic?)  In addition, patmatch works on this example without using nonunit 

Here is an example

restart;
the_rule:=A::nonunit(anything)+B::nonunit(anything)=A*B;
applyrule(the_rule,x+y);

              x*y

But nonunit is not needed for patmatch

restart;
the_rule:=A::anything+B::anything;
patmatch(x+y,the_rule,'la'); la

Successfull matching without nonunit

But from now on, will use nonunit with applyrule. This is good to know, and thanks for pointing this out, as I think applyrule is useful, if I can figure how to actualy use it correctly.

@Preben Alsholm 

applyrule is completely useless command. Consider this

rule0:=A::anything+B::anything=A+1/2*B;
applyrule(rule0,A+B)

It will loop forever.

Because applyrule computes the fix point, it applies the rules until no rule can be applied any more

And there is no way to tell it to applyrule only once. So it changes A+B to A+1/2B. Then since the result matches the rule, it will apply the rule again to give A+1/4*B, and it will keep doing this forever and ever. So I had to kill the session.

Compare to Mathematica

It will be good to have an option to tell it to apply the rule once. But no such option exists. May be in Maple 2032 we might get one. 

patmatch is much better,

rule0:=A::anything+B::anything;
patmatch(x+y,rule0,'la'); assign(la);
A+1/2*B

@Preben Alsholm 

"my conclusion is that applyrule is rather limited"

That is too bad. Because rule-based programming is very powerful in computer algebra (when it is done right).

Look at one of the answers given here https://mapleprimes.com/questions/235740-How-To-Emulate-This-Pattern-Operation-In-Maple- 

Where applyrule happend to work and how much shorter the solution became. 

But since it is very limited in Maple, it is not practical to use for many things where it would have been much more useful.

it can solve it without boundary conditions. Which is a hint that your BC could be inconsistent or such that it produces no solution. You might want to check the BC are correct.

      sol:=dsolve([OdeSys]);

solves it.

Maple 2022.2

@sursumCorda 

Thanks. Yes, you are right, applyrule seems the most direct way. It is also the closest to using Mathematica rule. I do not use applyrule and completely forgot about it. 

I wonder now why it is not used more vs. subsindets or patmatch since it seems from this example really easier. I will spend more time learning applyrule. I did use it before few times but for some reason I forgot now, I found it did not do what I wanted all the time. Need to visit it again.

Download apply_rule.mw