@Kitonum 

would you know why Maple choose in this example to give the solution the way it did, instead of the normal way, which would be 

                      y(x)=arccos(ln(x)+1)*x, y(x)=-arccos(ln(x)+1)*x 

i.e. a sequence of 2 solutions.

I find it very strange, why out of a sudden Maple choose this new new way to write out the solution. I find it confusing way to write out the solutions, given that Maple typically writes out solutions in clear way.

@vv 

I really understand what you are saying, I guess this is a philosophical question in a way.

Just as I view C=A/B the same as -A+C*B=0 just written differently, So I viewed   dy/dx=A/B the same as  -A dx+ B dy=0 just written differently and now it is exact, but if one views it as -A/B dx + dy=0 it is not exact.

So it depends how it is written.

But I ended up checking for both cases now. If the first form fails test for exact, then I try the second form of the ODE. So I am all set.

But I do get your point. It would hard for Maple to check different forms each time to find out.

@vv 

I can't enter Latex here. Here is screen shot

It is the same ODE, just written differently?  You are viewing moving the denominator to the other side as multiplication by integration factor? I did not look at it this way. I just viewed it as same ODE just written different.

@ecterrab 

thanks. I remember now running into this some time ago. The problem is that odetest worked using C[1] in my solutions may be for 99.99% of the time and only very rarely it failed. That is why I thought I did not need to change my code to use _C1 instead of C[1]. 

I do not use Maple's own solutions in odetest, but my own solutions. 

But it is resolved now. I simply changed my code to use _C1 and _C2 instead. I was first worried about using _C1 since I read that user code is not supposed to use variables with _ in front of them, due to possible conflict with Maple's own internal variables.

Issue is solved. Sorry if this caused any problems.

@AHSAN 

this is not what you wrote in your original question. In addition, I no longer understand what you are writing. In (22) you say diff(p(x),x) and in (23) you write diff(p(y),y)=0.  

Are these pde's and not ode's? I'll let someone else try to help you, as I am not able to understand your problem. good luck.

@lcz 

Instead of 

subs((5435 + 3*sqrt(515793))^(1/3)=t,s1)

You could try

simplify(subs((5435 + 3*sqrt(515793))=t^3,s1))

@Carl Love 

The solve evaluates to NULL

But I checked before. On 2020.1 

solve(x^2+a=0,x) assuming a>0

But I do not understand exactly what you mean by "Arguments are evaluated before being passed"

If solve is evaluated before being passed to timelimit, then what is the point of using timelimit in first place?

The whole reason to use timelimit is to prevent solve evaluation  from taking a long time? I must be missing something about what you are saying here.

But now I always add [ ] around solve inside timelimit. This has fixed things.

@Carl Love 

Thanks for your nice code example. It was useful to learn from.

But I was worried that if Maple introduce D(x),D(y),D(z), etc... as build-in operators, then many problems will start to result from users abusing this. For example, when I called your function using

ode:= -(x^2+x*y(x))*(D(x))^2 + D(y(x)) = 0:
convert(ode, standardODE);

ode:= -(x^2+x*y(x))*ln(D(x)) + D(y(x)) = 0;
convert(ode, standardODE);

I can come up with 1000 more such examples.

Ofcourse you could argue that the input should mathematically make sense to start with, but that is my point. Users can now type anything and abuse this notation to the limit and then expect Maple to figure what they meant.

Maple would have to do 100 times more work to parse the input to check it represents a valid differential equation since the D(x) and D(y) have been separated apart and they can be anywhere and inside anything. For example, What if there is an extra D(y) with no matching D(x), what does that mean mathematically?

If the purpose for the user wanting this notation, is to enter a differential equation, then they should simply use diff(y(x),x) standard notation. If the purpose is for something else, the OP did not explain why they needed this notation for. 

I just do not see the benefit gained from this complexity. I do not know of any CAS that supports such operations. May be there is a good reason why that is. 

no, there is no such thing, and there will never be such thing in CAS. It makes little sense and will cause all sort of problems.

Simplify write the ODE as normal using diff(y(x),x)

@Scot Gould 

but you did not mention the most important thing: did it autoscroll for you? i.e. when the print lines reach the bottom of the screen the first time, does it autoscroll so the last line being printed always shows up at the bottom of the screeen without having to manually scoll down to see it?

The whole reason I try to grab the bar on the right with the mouse, is to try to chase those lines being printed so I can see the last lines so I know the progress of the program.

@baharm31 

 If I add numeric I get an error.

I get no error on 2020.1

restart;
ode1:=-diff(q(t), t) - 1.851851852*10^(-7)*q(t)*(2.042885233*10^10 - 3.517396152*10^18*(0.00001474262739*cos((1000*sqrt(1122)*t)/33) + 0.00001474262739*sin((1000*sqrt(1122)*t)/33))^2) + 9.259259260*10^(-7):
ics := q(0) = 2.45*10^(-12):
sol:=dsolve({ode1,ics},numeric)

it works. I'll leave it up to you to check if the numerical solution is OK or not, as you know more what the solution should be. 

@mehran rajabi 

You can add assumptions to help Maple. Updated.

how is first  bc := q(-y) = 0, q(y) = 0  supposed to be boundary conditions?  since q is the dependent variable of the other ode. and the second bc bc1 := u(-y) = 1, q(y) = j  here u is the dependent variable from first ode. These BC do not make sense to me.

You can solve the ode without BC (need to fix the first one as well to change q to q(y)

restart;
ode := xi*diff(q(y), y, y) - N*diff(u(y), y) - 2*N*q(y) = 0;
ode1 := (1 + N)*diff(u(y), y, y) + N*diff(q(y), y) = p;
dsolve([ode,ode1],[q(y),u(y)]

I am really just curious, how would you suggest Maple should decide if f(x) is meant to be f*x  vs being just a normal function call f(x)?

@acer 

"I don't really understand why you want big_car:-set_name declared as static, "

Well, Maple help says to make all object methods static, to avoid making copy of them each time a new object instance is created. 

But in your solution, you changed the sub-module to become Object class. But this will now require changing all the signatures of its methods to use ::static, and not only that, but also adding the object name to each internal method API.

Which means changing 10's of internal API's inside the submodule and each call as well, which will break things.   

I also do not need to make instances of those modules, so making them Objects is not logically needed. I simply wanted to use the code they provide  from inside the object, but as private or local modules to the Object class.

But I ended up with just keeping them as separate modules for now. Like this

restart;	
module car_class()
      option object;
      local name::string :="UNKNOWN";

      export set_name::static:=proc(o::car_class,_name::string)
        o:-name := _name;
        big_car:-set_name(_name);
      end proc;

end module:

#separate module.
big_car :=module() 
   local big_car_name::string:="UNKNOWN";  

   export set_name :=proc(_name::string)
       big_car_name:=_name;
   end proc;        

end module;

This ofcourse works.

Only disadvantage is that big_car is module on its own, while before it was submodule or local module. 

So it is now not private to, or child to the object.

But it is not a very big problem for now. This way I do not need to modify many many API's just to make these modules child to the object. 

But thank you  for the suggestion.