See here for a related post.

You might also consider `eliminate`.

> eliminate({mu=n*p,(sigma)^(2)=n*p*(1-p)},{p,n})[1];
                                2                 2
                              mu            -sigma  + mu
                     {n = ------------, p = ------------}
                                2                mu
                          -sigma  + mu

> eliminate({mu=(1-p)/p,sigma^2=(1-p)/p^2},{p})[1];
                                        1
                                 {p = ------}
                                      mu + 1

> eliminate({mu=(1-p)/p^2,sigma^2=(1-p)/p},{p})[1];
                                        1
                               {p = ----------}
                                         2
                                    sigma  + 1

For either of those last pair, this seems to get you the explicit formulation of p (if such exists) instead of the implicit RootOf (using the "other" equation).

One thing that might help is if you specified what you wanted to happen when there was more than one explicit formula for the unknown(s) such as p.

> expr:=1+2*exp(x)+exp(2*x):
> factor(expand~(expr));
                                             2
                                 (exp(x) + 1)

> expr:=1+3*exp(2/7*z^3)+3*exp(1/7*z^3)+exp(3/7*z^3):
> factor(expand~(expr)) assuming z::real;
                                    3 (1/7)     3
                              (exp(z )      + 1)

Which version of Maple did you use?

The following seemed ok for me, in Maple 12.01 or 13.01.

Explore(plots:-polarplot(1+a*cos(theta), theta = 0 .. 2*Pi));

When the first pop-up window showed, I ticked the box to skip `theta`. And I changed the `a` range endpoints to be floats like 0.0 and 10.0 (the effect of which was that the associated Slider allowed more than just the intermediate integer values).

And since my setting is for Maple to always ask, I selected New for the kernel of the new sheet, instead of choosing to reuse any kernel running any other already open sheet. I think that most people will have this setting to always use a new kernel, so they don't see that other pop-up.

What's the reason for the insistence on a series? Was it specially requested by a course instructor? Expressed as a call to the "special function" LambertW, Maple knows how to further mathematically manipulate, convert, differentiate, integrate, plot, and evaluate exactly when possible or accurately at floating-point values  in most all ranges, etc.

A series form for LambertW either has to be the call to Sum (Sigma) with an infinite index bound, or a curtailed collection of finitely many terms. The first is not a closed form solution. The second is a curtailed sum whose accuracy at approximate float values you do not know in general. Also, you may only have a finite, and possibly small, convergence for that series representation (even considering all infinitely many terms).

So-called special functions like BesselJ, LambertW, etc, are common. They have no general closed-form representation in terms of a finite number of arithmetic operations and powering. Sometimes they can be considered as representing solutions for some differential or integral equations which are not otherwise explicitly solvable. Maple often has some extra knowledge about that, and sometimes can make extra use of it.

The functions sin, cos, arctan, exp, and ln can be taken to be in this broad category. What should we answer to someone who objects to the use of sin(x) and insists on only considering a truncated series of a few terms?

If there is no good reason for a truncated series, then don't insist on it. Accept the LambertW form, and optionally add a note showing it's definition (and infinite series form if you really feel it benefits anyone) to your paper or report.

> restart: with(Statistics): nops(%);
                                      140
 
> restart: with(Statistics,Fit,NonlinearFit); nops(%);
                              [Fit, NonlinearFit]
 
                                       2

Maple will apply the evalb automatically here, so those evalb's are a (small but) unnecessary additional cost. There may be much more efficient ways to do this task for very large listlists, so it doesn't matter much here.

But in general you want to avoid programming anything like this too

if evalb(....) then ...

Is this what you want?

> a := [[1, 7], [2, 3], [5, 4], [1, 2], [8, 9], [7, 9], [1, 6]]:

> sort(a, (x, y) -> x[1]<y[1] or (x[1]=y[1] and x[2]<y[2]) );
           [[1, 2], [1, 6], [1, 7], [2, 3], [5, 4], [7, 9], [8, 9]]

What if your file is saved as .mws instead of .mw, before you call makehelp? Does that work better for you, for subsequent viewing in the commandline or Classic interfaces?

I'm not sure that Matlab:-FromMatlab knows how to translate calls to Matlab's arrayfun. But maybe you/we could tell it how, using Matlab:-AddTranslator. It may often translate to a map or map2 call.

But first, you'll have to either upload your actual source file (green arrow icon in the mapleprimes editing bar, right above where you enter your post) or paste it in full. It looks like you're missing a lot of the brackets in what you originally posted. Did you mean to post Matlab strings a bit like these?

arrayfun(@(p) r.^p, rpowers(2:end) ,'UniformOutput', false)

arrayfun(@(p) r.^p, rpowers(2), 'UniformOutput', false)

If it helps you any, here is piece of Maple code using map and also elementwise `^`. Sorry if I'm not close, as I'm guessing about your source. I've tried to replace your anonymous function "@(p) r.^p" with the Maple operator "p->r^~p" which I hope is right for you, to raise each element of r to the power p.

> r:=<1,3,5,7>;
                                        [1]
                                        [ ]
                                        [3]
                                   r := [ ]
                                        [5]
                                        [ ]
                                        [7]
 
> rpowers:=<1|2|3|4>;
                            rpowers := [1, 2, 3, 4]
 
> map(p->r^~p, rpowers(2..-1));
                             [[ 1]  [  1]  [   1]]
                             [[  ]  [   ]  [    ]]
                             [[ 9]  [ 27]  [  81]]
                             [[  ], [   ], [    ]]
                             [[25]  [125]  [ 625]]
                             [[  ]  [   ]  [    ]]
                             [[49]  [343]  [2401]]

It could get interesting, trying to deal well with both true and false values of arrayfun parameter UniformOutput.

> restart:
> X := Vector([1, 2, 3, 4, 5, 6], datatype=float):
> Y := Vector([2.2, 3, 4.8, 10.2, 24.5, 75.0], datatype=float):

> solmod:=Statistics:-NonlinearFit(a+b*v+exp(c*v),
>                                  output=solutionmodule):

At that point, you issue commands such as

solmod:-Results();

or get individual results such as

solmod:-Results("residualsumofsquares");

solmod:-Results("residualstandarddeviation");

solmod:-Results("residuals");

etc.

Figuring out the specification for an equivelent Maple routine isn't as easy as it could (should) be, if the only reference is to another program's help page. It entails figuring out  the other program's syntax. It's not impossible, but you could make it easier for us.

And that page's "examples" section doesn't show the full output, does it?

Perhap you could give a few characteristics examples of the input and desired output (just as Maple lists, say)? Do you want to be able to mimic all the optional switches on that R function?

    ListTools:-LengthSplit(a,2);

Why try to assign to the higher level L anyway? The procedure is already creating new lists from old (lists only appear to get acted upon in-place, even with subsop!), so any ostensible inplace action to the higher level L isn't any real savings.

And globals are generally ugly and can bring their own problems (thread safety, evaluation inefficiency, etc). They are only slightly less uglier than side-effects on ::uneval parameters or named arguments passed quoted.

Why not have the procedure first copy argument L to a local variable LL, then do all those actions on LL, and then have the proc return LL at its end?

Can it not be done even easier than that. Rename the argument L to be LL in the proc's parameter list. Then put L:=copy(LL) at the top of the procedure, and return L at its end. The rest could likely remain as is (modulo fixes and other improvements, of course).

Your example has three purely real roots. So the `b` is exactly zero for each of them. What you get for a+b*I after convert/rational is just the `a`, then. Why is that not adequate?