Any idea why symgen hangs when using formal algorithm on this first order ode? I was just comparing the Lie symmetries generated for this ode using different algorithms when I noticed this hang on formal.

The textbook gives this result btw

From help on symgen it says

The first algorithms, called formal, formulates a linear PDE system for the infinitesimals [xi, eta], then formally triangularize this system - using differential algebra techniques - finally tacking the resulting uncoupled system. When successful, this algorithm returns the complete set of point symmetries admitted by a given ODE of order 2 or higher. NOTE: this algorithm is advantageous mainly for 2nd and higher order ODEs. The algorithm works as well in the case of first order ODEs, but in this case the subproblems it will need to solve to find the symmetries are as difficult to solve as the first order ODE itself.
 

But on Maple 2020.1 server seems to hang, taking 100% CPU. I had to terminate mserver.exe manually since clicking on interreupt button from worksheet has no effect. This only happens with formal algoritm. All others work very fast. 

I know help says this is meant for second order ODE's, but it also says it works  well for first order.  It seems to be stuck in solve call somewhere. Is this to be expected sometimes when using formal algo in symgen for first order ode's?

Maple can solve the ODE very quickly otherwise.

The following ode also hangs in symgen

ode:=diff(y(x),x)=x*y(x)^2-2*y(x)/x-1/x^3;

Download symgen_issue_1.mw

The following transfer function has zero/pole cancelation. I am trying to create a transfer function object, but Maple automatically simplifies the transfer function before it gets to the DynamicSystem call, which result in different output than what I expected.

I do set the cancellation=false option, even though this is the default. The problem is Maple does pole/zero cancelation before the call.

I tried to add '' around it to delay evaluation, but it did not work.  

restart;
alias(DS=DynamicSystems):
DS:-SystemOptions(cancellation=false,complexfreqvar=s):
tf:=DS:-TransferFunction('-(s - 1)/((-2 + s)*(s - 1))'):
DS:-PrintSystem(tf)

You can see it did pole/zero cancelation.

In Matlab and Mathematica, this does not happen. For example

Clear["Global`*"];
sys = TransferFunctionModel[-(s - 1)/((-2 + s) (s - 1)), s]

Same with Matlab:

>> s=tf('s');
>> sys_tf =-(s - 1)/((-2 + s)*(s - 1))

sys_tf =
 
     -s + 1
  -------------
  s^2 - 3 s + 2
 
Continuous-time transfer function.

What do I need to do in Maple to keep the transfer function without pole/zero cancelation (this affects the state space realization later on when this cancelation happens)

I am using Maple 2019 at this moment as Maple 2020 is busy.

As I was going over latest build using Physics:-Latex I noticed this.

The complex number I should be translated to lower case i  in latex.

This is what the original latex() does (and also what Mathematica TeXForm does).

It does not look good at all to have complex number I be translated to I and remain UPPER case I

Here is an example

expr:=[solve(x^2+2*x+2=0,x)];
Physics:-Latex(expr)

gives

[-1+I, -1-I]

While  latex(expr) gives the much better and more mathematical output:

[-1+i,-1-i]

Is it possible to have Physics:-Latex translate complex numbers like latex() did?

Please see attached worksheet below.

Download latex_issue_9.mw

I'd like to suggest Physics:-Latex change its use of \textit{} and replace it with \mathit{} 

\mathit is the better Latex command to use, since the Latex generated goes into math mode and \mathit is designed to be used in math mode and hence has a better spacing for this. Making the final Latex look a little better.

Here is an example showing the difference.

restart;
ode:=diff(y(x),x) = y(x)/(x^2+1);
sol:=dsolve(ode);
Physics:-Latex(sol)

Gives

y \left(x \right) = \textit{\_C1} {\rm e}^{\arctan \left(x \right)}

It will be better to generate

y \left(x \right) = \mathit{\_C1} {\rm e}^{\arctan \left(x \right)}

Here is the difference when both are compiled using latest texlive 

Since all the Latex generated is meant to be used in math mode, \mathit would be better choice. It is considered wrong to use \textit in math mode actually, even though it does compile.

Here is the latex file used to generate the above pdf

\documentclass[12pt]{article}
\usepackage{amsmath}
\usepackage{maplestd2e}


\begin{document}

\[
y \left(x \right) = \textit{\_C1} {\rm e}^{\arctan \left(x \right)}
\]

\[
y \left(x \right) = \mathit{\_C1} {\rm e}^{\arctan \left(x \right)}
\]

\end{document}

thank you

Download latex_issue_8.mw

I've been using Physics:-Latex in my large program, and checking the output visually. I noticed this small issue on one page.

When asking Physics:-Latex to generate Latex for this expression

It gives

While when using standard latex() command, the result is

Below is the worksheet attached. Using Latest Physics and Maple.
 

THe latex file used to compile the Maple output Latex using TeXLive distribution on Linux is

\documentclass[12pt]{article}
\usepackage{amsmath}
%\usepackage{maplestd2e} %not needed for this example
\begin{document}

%output of Physics:-Latex()
\[
\frac{\left(\int {\rm e}^{-t} f \left(t \right)d t \right) {\rm e}^{t}}{2}+-\frac{1}{2} {\rm e}^{-t} \left(\int {\rm e}^{t} f \left(t \right)d t \right)
\]

%output of maple latex()
\[
{\frac {\int \!{{\rm e}^{-t}}f \left( t \right) \,{\rm d}t{{\rm e}^{t}}}{2}}-{\frac {{{\rm e}^{-t}}\int \!{{\rm e}^{t}}f \left( t \right) \,{\rm d}t}{2}}
\]

\end{document}

Download latex_issue_5.mw