One way to make it work is by placing the .lnk shortcut file for cmaple.exe in your desktop directory, so that you get an icon for this shortcut on your desktop. Then you throw your .mpl source file onto it by dragging its icon with the mouse. It should get executed minimized.

I prefer handling such processes through the file manager. I use Total Commander and I would create a custom button which launches a suitable script. Surely, there is a lot of software tools around with similar capabilities, suitable for every taste.

See this thread for a bit more of information on this subject.

The behavior 3* [a,b] = [3*a, 3*b] arises from automatic simplification, which does not call the builtin `*` routine:

> trace(`*`):
> 3*[a,b]; 
                                   [3 a, 3 b]

So, an overloaded version of `*` will not be called either. And, as the automatic simplification is at the very core of the Maple design, you cannot prohibit it (rather you have to live with it...).

There is no general rule. Sometimes it is easy to share objects and results between packages in a direct or not too complicated way, but frequently not (you may need to write "matching" procedures). Maple is more a confederation of routines and packages than a coherent system with unified design...

There is no general rule. Sometimes it is easy to share objects and results between packages in a direct or not too complicated way, but frequently not (you may need to write "matching" procedures). Maple is more a confederation of routines and packages than a coherent system with unified design...

This behavior is documented in ?worksheet,documenting,2DMathDetails :

For a product containing integers and decimals, implicit multiplication can be used only if the number occurs in the left-most position in the product.

Yet, I find it remarkable that it is considered fine a noncommutative implementation of a commutative operation.

This behavior is documented in ?worksheet,documenting,2DMathDetails :

For a product containing integers and decimals, implicit multiplication can be used only if the number occurs in the left-most position in the product.

Yet, I find it remarkable that it is considered fine a noncommutative implementation of a commutative operation.

Most likely it will be impossible to realize for a general TeX/LaTeX construct. You could not expect miracles! But if it can be make work for a suitable subset, it would be worthwile, in my opinion. In your Mathematica example, I think that the constraint is given by the  ToExpression command working as "inverse" of the TeXForm command. So, using as input for the second command a syntax following the output of the first one, it does work:

In[1]:= TeXForm[mu[D]*Log[1/(1-r)]]
Out[1]//TeXForm= \mu (D) \log \left(\frac{1}{1-r}\right)
In[2]:= ToExpression["\\mu (D) \\log \\left(\\frac{1}{1-r}\\right)", TeXForm]
              1
Out[2]= Log[-----] \[Mu][D]
            1 - r

Possible bugs aside, it does not look so bad for me. Moreover, it could be used as another workaround: convert from TeX to Mathematica input, and then in Maple convert that Mathematica input using FromMma ...

Most likely it will be impossible to realize for a general TeX/LaTeX construct. You could not expect miracles! But if it can be make work for a suitable subset, it would be worthwile, in my opinion. In your Mathematica example, I think that the constraint is given by the  ToExpression command working as "inverse" of the TeXForm command. So, using as input for the second command a syntax following the output of the first one, it does work:

In[1]:= TeXForm[mu[D]*Log[1/(1-r)]]
Out[1]//TeXForm= \mu (D) \log \left(\frac{1}{1-r}\right)
In[2]:= ToExpression["\\mu (D) \\log \\left(\\frac{1}{1-r}\\right)", TeXForm]
              1
Out[2]= Log[-----] \[Mu][D]
            1 - r

Possible bugs aside, it does not look so bad for me. Moreover, it could be used as another workaround: convert from TeX to Mathematica input, and then in Maple convert that Mathematica input using FromMma ...

It is not a bug, in the restricted sense, as this is the documented behavior. However, I would qualify it as a design bug, see this thread.

It is not a bug, in the restricted sense, as this is the documented behavior. However, I would qualify it as a design bug, see this thread.

@pagan Interesting, I do not get them on Linux 32-bit Maple 15.01. Another Win vs Linux or 32 vs 64-bit issue?

@pagan 

In Maple 15.01 I get a different result without piecewise:

> int(abs(cos(n*x)),x=0..Pi,AllSolutions) assuming n::posint;
                                       2

Idem for the negint case. And the same in Maple 14.01, while it is present for both cases in Maple 13.02. Anyway, the conditions in piecewise do not imply that Pi is a variable. As in this toy example:

> piecewise(Pi=Pi/(2*n),1,0);
                              {               Pi
                              { 1        Pi = ---
                              {               2 n
                              {
                              { 0        otherwise

The condition is actually on n.

> simplify(%);
                              { 1         n = 1/2
                              {
                              { 0        otherwise

Certainly, the resulting conditions n=1/2 or n=-1/2 are incompatible with the assumptions n::posint or negint, or for n=13,14,...

Just in case, see here. Again, the first purpose of my suggestion to test with Classic would be gathering further evidence that the poblem lays with Java. If this were the case, that is, if there were an incompatibility between that desktop keystroke acceleration and Java, it seems to me that you will have to choose losing something, as there is no sign that Maplesoft will provide an alternative non-Java GUI, nor allow a third party do it.

Just in case, see here. Again, the first purpose of my suggestion to test with Classic would be gathering further evidence that the poblem lays with Java. If this were the case, that is, if there were an incompatibility between that desktop keystroke acceleration and Java, it seems to me that you will have to choose losing something, as there is no sign that Maplesoft will provide an alternative non-Java GUI, nor allow a third party do it.