@Carl Love 

opps, you are right. I forgot this rule. So maple's Math is the correct one.  I need to go have more coeffee.

@Christian Wolinski 

I thought that is what it did, this is why I asked if order matters. But that would be really wrong design if this was the case. Also help says

And dictionary says  that simultaneous means:  occurring, operating, or done at the same time.

So it should be doing the substitution in "batch mode", ie, at same time. Not do one. Evaluate the new expression, and now do the next replacement on the new expression, which ofcourse could now have changed, reshuffled, order of operands might change, number of operands changed, and so on. This design would make no sense from the user point of view if this was the case, right?

But who knows. May be help is wrong and may be it works as you said.

fyi, this gives zero

VectorCalculus:-Laplacian(1/r, 'spherical'[r,phi,theta] )

                         0

@Preben Alsholm 

Thanks. But I am little confused what is the bottom line here. Is this a bug in has?

But if one wants to write a function that takes in P, where P is the plot generated by DEplot, and return true of false depending if the plot is empty or not, then what will this function looks like based on what you found above?

@sursumCorda 

are all allowed

Not on V Maple 2023.2. The last fails.

I looked for this sometime ago, and could not find one. Yes, it will be nice to be able to do the same as Matlab. But nothing like ~ exist in Maple as far as I know.

@Carl Love 

Thanks. That is good to know. I had no idea that subs will do it, as I use eval() all the time to replace symbols in expression.

It seems because subs does not do evaluation it worked in this case. It is really hard sometimes to figure out when to use eval and when to use subs when one wants to replace things in an expression. But in this example, will use subs then.

@Carl Love 

Yes, I understand why it failed when using curved. I knew it is because it did something different that when the arrow is not curved.

But this is really beside the point. These are internal detailes the user of the software should not care about.

When I write a function that takes two options, and it fails when using option 1 but does not fail when using option 2, then this  is a fault of my function. Not the user for using wrong input.

Software should be robust and not fail like this. For example, if Maple is not able to do it internally using curve arrow for some cases, it should internally handle this. May be not process the curve at that location and leave it empty and go on to the next location. Or may be do something else.

But it should not give an exception.  

@Carl Love 

Please see what I wrote above about it failng ONLY when using 'arrows'='curve'. My code works fine using y = -1.6 .. 1.6 when not using the option arrows = 'curve'. That is the whole point of what I am asking.

restart;
ode := diff(y(x), x) - 1/(-x^2 + 1)^(1/2) = 0;
x_range := -0.99 .. 0.99;
DEtools:-DEplot(ode, y(x), x = x_range, y = -1.6 .. 1.6, [y(0) = 0]);

works fine.

restart;
ode := diff(y(x), x) - 1/(-x^2 + 1)^(1/2) = 0;
x_range := -0.99 .. 0.99;
DEtools:-DEplot(ode, y(x), x = x_range, y = -1.6 .. 1.6, [y(0) = 0],arrows = 'curve');

error

So I expect the software to not fail when using arrows = 'curve'

@sursumCorda 

Yes, VectorPlot in Mathematica might be closer to Maple's DEplot. But I was looking for something similar to StreamPlot to make PhasePlot since it looks better than VectorPlot. Using arrow='curve' in Maple's got it a little closer to StreamPlot, but there is a bug with arrow='curve'. 

@C_R 

Yes, I knew that if I change the range randomly the bug will go away. But this is not practical solution. And what will I do for for next 10,000 systems I am processing? Keep trying different ranges each time randomly until I find one that does not crash Maple?

Hopefully Maple will fix this in next version. 

Too many bugs, crashes and hangs in Maple. And it keeps getting worst with each new release.

@Rouben Rostamian  

That is better. I knew about arrowsize=number option and did try before. The problem with this, is that I want to run this code on thousands of systems, and if I hard code it to 1.5, it might look OK for some systems, but might look bad for others.

May be others need arrowsize=1.5 and some need arrowsize=2.0 and so on. I do not know.

It would have been better if Maple had an option to make the lines all connected and put the arrows on them, like with Mathematica's. 

But for now, will try 1.5 and see how it works. The axes=boxed and color='magnitude[legacy]' helped. make it better. thanks.

btw, why on your version the tick labels and the axes labels look bigger and darker than what I get? I am on windows 10, Maple 2023.2. This is what I get

I run your code as is, after restart. It looks like your fonts are different than what I am using. Did you by any chance modify some settings in your Maple before this? Your fonts look better than what I am gettings.

@Joe Riel 

"In module A, s has to be an export, not a local."

I know if I make s global, it ofcourse works.

But the question is why is this needed?? This is a workaround not an explanation. 

Not only this change will break encapsulation, it does not explain the problem to me.

When class B extends class A, they become as one single class. So the new class is as if one have written the following code

module A()
   local s::string:="";
   export foo:=proc()
     local z::string:="something";
     local my_inner_proc:=proc()
            s:=cat(s,z);
     end proc();
     my_inner_proc();
     print(s);
   end proc:
end module:

A:-foo();

And the above works as expected.

s is local to the module and an inner method inside the one of the module methods can access the top module local variable and modify it without s having to be global.  But the above _fails_ when adding option object:

restart;

module A()
   option object;
   local s::string:="";
   export foo::static:=proc(_self,$)
     local z::string:="something";
     local my_inner_proc:=proc()
            _self:-s:=cat(_self:-s,z);
     end proc();
     my_inner_proc():
     print(s);
   end proc:
end module:

A:-foo();

Error, (in anonymous procedure called from anonymous procedure) module `A` does not export `s`
 

My question  is why it fails when the module is object vs. normal module.

If this is a design error in Maple OOP, fine. May be it can be corrected in next version. For now, only workaround I found, while keeping object local variable private, is not to use internal methods inside class methods. 

@C_R 

"The required restriction to a part of the real domain is an indication that the MMA response may be too short for the complex domain."

Not when done in Mathematica?

No assumptions or restriction needed.

@sursumCorda 

 is there a similar sortrows/sortcols in Maple?

you might want to look at ArrayTools[SortBy] which is new added in Maple 2023