Is there a problem with Maple primes?  

When I want to ask a question, the input panel is disabled and not possible to type into it. Here is screen shot.

Same when I wanted to make a reply to an answer. I can not type into the window that shows. It is like disabled.

I found I only can write here, in the post section.

What is the problem?  

Every time I convert Mathematica expressions to Maple in order to use them there, I have to spend hrs by hand adding () around places in the input Mathematica expression because Maple complains about a^b^c.

The problem is that Mathematica has no problem with this, as it always takes a^b^c as a^(b^c). Here is an example to illustrate

But in Maple

MmaTranslator:-FromMma("E^x^2")

So I have to edit the input by hand

MmaTranslator:-FromMma("E^(x^2)")

The problem is that this is how Mathematica produces the expressions, and I have no way to tell Mathematica to put an extra () around to clear this ambiguity,

So I am hoping there is a way in Maple to do it. May be using some option? I know even using Maple own expressions, it complains about this:

x^y^z

But in Mathemtica it accepts this

If there is no way to change this behavior maple, else it means I have to spend hrs again editing all the Mathematica input by hand before using MmaTranslator:-FromMma each time. There are 100's of these in each file.

I think Maple here is not behaving the same as other CAS system. In Fricas it also works as is

(1) -> x^y^z

          z
         y
   (1)  x

Same in Maxima

(%i2) x^y^z;  
                                        z
                                       y
(%o2)                                x

Same in Giac

0>> x^y^z
x^(y^z)

And in every other CAS system I tried. It is only Maple who complain about this.

Any suggestions for workaround?

This is a much simplified version of a problem I am seeing. I think I have to remove all the coerce code I added as it seems to have problems.

Made an object with constructor that take an optional argument. These optional arguments use coerce to convert different types on one type of list.

I have another proc foo() that is called with these arguments, also same optional ones, and it then creates the object passing these arguments to it. 

The problem is that if foo() is called with an optional argument itself, which will default to empty list [], I am not able to create the object now, when doing  ':-ic'=ic  since debugger gives 

Error, invalid input: too many and/or wrong type of arguments passed to ModuleCopy; first unused argument is [] = []

Even though I made sure to pass the optional argument using  ':-name'=value.

The strange thing is that this only shows in the debugger. i.e. when typing the command in the debugger window. But in my application, it does not work inside the debugger and outside since it is much more complicated setup.  This is the simplest example I could make to show the same error in the debugger.

A small example will show the problem.

restart;
A:=module()
   option object;
   export ode;
   export ic;

   export ModuleCopy::static:=proc(_self, proto::A, ode::`=`,
                    { ic::coerce( (ic::list(`=`))->ic, 
                                  (ic::set(`=`))->[ic[]],
                                  `:-NoUserValue`):=[]
                    },$)
        print("ode=",ode);
        print("ic=",ic);
    end proc;
end module;

foo:=proc(ode::`=`,{ ic::coerce( (ic::list(`=`))->ic, 
                     (ic::set(`=`))->convert(ic,list),
                     `:-NoUserValue`):=[]
                    },$)
    local o;
    DEBUG();
    o:=Object(A,ode,':-ic'=ic);
end proc:

# and now

foo(diff(y(x),x)=1)

Now the debugger window shows at the line above just before calling the object constructor. This is what happens next

But if I click continue it does not produce an error and actually works. (in my main application, with similar setup, it gives an exception).

If I can figure why debugger gives this error, may be that will help me figure my more complicated setup.  I know if I do not use coerce, the debugger error goes away. Here is a version without coerce, and it works

restart;
A:=module()
   option object;
   export ode,ic;
   export ModuleCopy::static:=proc(_self, proto::A, ode::`=`, { ic::list(`=`):=[] })
        print("ode=",ode);
        print("ic=",ic);
    end proc;
end module;
                  A := Object<<2457889631168>>

foo:=proc(ode::`=`, { ic::list(`=`):=[]})
    local o;
    DEBUG();
    o:=Object(A,ode,':-ic'=ic);
end proc:

#now do
foo(diff(y(x),x)=1)

Now the debugger window comes up, but now see the difference:

No error!  even though  `ic` was [] in this case also, like the first example.

So for now, I will remove all the coerce code just to get my application to work again even though I like it, but it seems to cause a problem.

question: What the first example above given an error in the debugger?  

Notice this error only shows up when using a module of type object. 

Update

This is just to confirm that removing the coerce API and replacing it back as it was with traditional optional arguments as in the second example above the exception went away.  My code is way too large to post here, but that is the only difference I have.  I think there is a problem using coerce with Object constructor calling somewhere.  But I am OK now, and able to continue work.

I have some of my main functions defined to take input in different formats. Some have required  parameters and also optional parameters. Similar to how say dsolve can take one ode, or a list of ode's or set of ode's and also other additional arguments.

Currently I use something like  ode::{`=`,set(`=`),list(`=`)} in the signature of the proc to indicate this input can be any of these types. There are also optional aguments.

So inside the proc, it does lots and lots of if this then do such else do such type of logic in order to determine which case/combination of input it is called with.

I am thinking of rewriting all of the API to use overload. Yes, it means I will have lots of copies of the same proc, each to handle specific case of the signature. But it also mean it will be now much simpler inside each of the overloaded proc's to determine which case of call it is processing.

I'd like to ask, is there anything to be aware of before making this change? does it affect performance much? It seems to me it will make the logic and the program simpler.  Here is a very simple example to illustrate.

Which you think is better? I like the overload version more. But I am worried that I will end up with too many versions of the API since I need one for each possible combination and may be this will slow Maple down? 

The following is the worksheet also.

Download overload.mw

I can not find my Kamke book right now. But according to Maple help, Homogeneous ODE of Class C is the following

If I understand the above, it is saying that the RHS of the ode should be ratio of two polynomials, and both should be linear in y and x. Correct?

Given the above, then why Maple says the following ode is _homogeneous, `class C` ? Since the RHS is not linear in y and not linear in x:

restart;
ode:=diff(y(x),x)=(2*y(x)-1)*(4*y(x)+6*x-3)/(y(x)+3*x-1)^2;
ode:=lhs(ode)=expand(numer(rhs(ode)))/expand(denom(rhs(ode)))

DEtools:-odeadvisor(ode)

           [[_homogeneous, `class C`], _rational]

What Am I overlooking/misunderstanding  from reading this definition?