@Carl Love 

thanks. yes, That fixed it. Now all tests pass.

@Carl Love 

I think what happens is this. DEtools:-odeadvisor(ode,y(x),[linear]) rewrites   (x+y)*y'=0 as two equations. one is (x+y)=0, which is algebraic and gives solution y=-x, and the other is y'=0, which is an ode which is linear with solution y=constant.

But if looking at the ode as is , then the ode is clearly not linear _before_ factoring it out. So the question is, should DEtools:-odeadvisor(ode,y(x),[linear]) look at the ode as is to decide if it is linear or not?

I think so. But clearly that is not what it is doing now.  When actually solving the ode, factoring it is the right approach. But not for the advisor. That is my point.  Because now, I can't use the advisor to check if the ode is linear in order to check before calling convertAlg

May be Maple needs a new build in method to check if an ode is linear or not?

@Carl Love 

I rewrote the question to make it more clear.

@Carl Love 

But that is what I said. But the code I have uses

DEtools:-odeadvisor(ode,y(x),[linear]);

To check if the ode is linear or not before calling convertAlg and this is how I found this error. 

So the problem is that DEtools:-odeadvisor(ode,y(x),[linear]); should not have returned _linear as result. Now I have to go back to using my own code to check if an ode is linear or not.

@Carl Love 

Fyi, I found a bug. Added it to the tests. (and corrected y to y(x) in two of the odes, that was a typo).

Attached is the complete worksheet. The last ode gives degree as 1, it should be 3.

Last ode is y(x)-x*diff(y(x),x)-1/2/diff(y(x),x)^2=0 which is the same as shown below, which is obtained using the command  PDEtools:-dpolyform(ode)

Download different_degree_second_test.mw

@ecterrab 

Fyi, I found another example where de_degree returns different result depending on how the ode is written,

Please see attached worksheet

Download different_degree.mw

@Carl Love 

The definition does not exclude the possibilities f=0 or g=0.

Are you saying that y(x) = g(p) can be dAlembert? for what conditions on g(p) ?

In this case, then y(x)=ln(diff(y(x),x)) and y(x)= tan(diff(y(x),x)) and so on all are now dAlembert. But clearly these are not. These are all quadrature.

But by adding an x to both the above examples, they now become dAlembert. y(x)=x*ln(diff(y(x),x)) and y(x)= x*tan(diff(y(x),x)) are dAlembert. (g=0 case is allowed)

So if y=g(p) can be dAlembert (i.e. f=0 is allowed), what are the conditions on g(p) for this to be the case? Otherwise, this is all fussy definitions.

In all the text books I looked at, I never seen an ode called dAlembert which had a missing x on the RHS (i.e. f=0 case) . But may be I did not look at enough examples.

try MmaTranslator  andFromMmaNotebook

But do not expect it to work on such large notebook with other non-mathematical functions in it. This translator is meant to be used to translate basic Mathematica math constructs.

Not to translate Full Mathematica code (otherwise, people will just use Maple to run Mathematic code for everything, which means Maplesoft will have to implement all of the Mathematica kernel in it, which is about 50 millions line of code or so). For example, do not expect the Plot commands to be translated to Maple.

My advice to translate this, is to do manually. Try to implement the algorithm itself in Maple directly, and do not translate line by line. I use this Maple translator to translate individual Mathematical expressions from Mathematica to Maple (which is very useful to have), but not to translate full functions and packages. Will not work for that.

@Christian Wolinski 

Thanks. It does fail on cases where the function shows up as argument to itself. But I do not think I have such cases, so this should not cause a problem.

restart;
C := proc(E, T)
   if type('E, T') then 1 elif hastype('E, T') then add(map(procname, [op]('E'), 'T')) else 0 fi;
end;
expr:=sin(sin(x));
C(expr,'specfunc(anything,sin)');  # gives 1
nops(indets(expr,'specfunc(anything,sin)'))  # gives 2

it would have been better if you attached such problem worksheet to use as an example. I do not see this problem you are talking about. But I do not use Maple to export pdf files much if any. I export what I want from the worksheet to Latex and compile the Latex to pdf. You get much better quality pdf this way.

But to change the font size in pdf, there are many external tools to use. Some are free, and some are not.

Adobe itself has an online service that does that Here is the link  https://www.adobe.com/acrobat/hub/how-to/change-font-size-in-pdf  

etc..

@Joe Riel 

This change was meant to be applied/used only within MmaTranslator:-FromMma package and not anywhere else in Maple. 

Since the expression x^y^z is a valid Mathematica expression and the Maple package is meant to be able to translate any valid Mathematica  Math expression to Maple, then it will be better if it can translate this to Maple, using a default internal setting  to generate x^(y^z) as translation to Maple.

Within Maple, it is no problem at all adding explicit () when needed.

That will something useful to have in Maple 2023 if possible. 

@acer 

Thanks! You are right, I am now using Chrom browser and able to write this here as you see,. 

But from Brave browser, which is the one I use all the time as it is more safe (no ads), when I login, this window is disabled for some reason.

I will try clearing the cache from the Brave browser to see if this has anything to do with it.

@tomleslie 

@Carl Love 

The debugger comes up automatically (when you uncomment the DEBUG(); statement). Then in the small window there (below where it says to enter a debugger command) I simply type

Object(A,ode,':-ic'=ic); 

This is to see what happens, without hitting the STEP button. i.e. just type in the window the actual Maple command which is about to execute. The error will show. At least it does on my Maple.

This is very useful feature. It allows one to issue Maple commands inside the debugger and examine things right at the place where there is a problem.

I do not know how you program without a debugger. You must be very good. I get lost without a debugger :)

@Carl Love 

Thanks. But the debugger gives same error. Here is screen shot. I am on windows using 2022.1

another screen shot

Do you not get same error?  

I now find the traditional optional argument handling easier to work with actually. Yes, I have to add few explicit IF THEN ELSE to check for each possible type and do an explicit casting. But this is not too bad, at least I get no strange errors like with corece. So my code now looks something like

if type(ic,set) then
     _self:-ic:=convert(ic,list);
elif type(ic,Vector) then
     _self:-ic:=convert(ic,list);
elif ....etc..
fi;

I do this each argument which can have different type