Don't make the mistake of trying to assign to f(x) .

Instead, assign the expression x^(3/2) to just f the name.

Download int_example.mw

The MatrixExponential command passes off to the MatrixFunction command, which in turn calls the Eigenvalues command.

If you convert the entries in H2 so that the coefficients are exact rationals then it works. (Or in you make all the entries floats, as in your H3, it works.) What it doesn't like are the symbolic names in entries with float coefficients.

Download MatrixExponential_rationalsymbolic.mw

The error message from Eigenvalues is being re-thrown usefully by MatrixFunction, but not by MatrixExponential.

It looks like Eigenvalues could in principle be made to succeed for your particular H2 example (but it might help MatrixFunction, and Eigenvectors it seems) if some simplification or other intermediate handling of the results were attempted.

[edited] It seems that conversion to trig form also works, even with the floats present. (I suppose it might just happen to do better because Eigenvalues does better with it.)

Download MatrixExponential_rationalsymbolic_2.mw

[edit] I should that the double-indexing approach is relatively much less efficient. And add will be more efficient than sum. So for larger examples you'd have the choice between prettier 2D input versus efficiency.

Download sumadd.mw

After assigning that value to the name complex1, then try,

convert(complex1, phasor);

You could also right click on the output of complex1 and choose the context-menu item Conversions->Phasor form...

Apart from not assigning to gamma and psi (because you want to solve for equations involving them), what's the particular difficulty?

If you don't want to declare gamma as a local name then change it to something else (eg, just g). Maple considers :-gamma to be a known constant (similar to how it knows what Pi is, etc).

Download fsolve_couple.mw

Here are two ways.

The first way is similar to just,

Matrix(40, 151, {op(op(eval(T)))});

but it also figures out the dimensions for you.

Download table_to_Matrix.mw

[Note: issues with LPSolve and 64bit Windows are known, in the sense that multiple reports have been made previously. Sometimes it manifests as a crash, and sometimes as a spurious failure to find a feasible point, or a spurious message about the problem being unbounded. I might first suspect a mismatch in the width of hardware integers (or arrays of such) being passed (including to the MKL) externally. But it's very curious: machines either exhibit the problem, or they don't. I've heard of 64bit Windows 7 machines that show it, but my three 64bit Windows 7 machines don't. It's be nice to see this resolved.]
[Note: everything below is in 64bit Linux, which does not exhibit the crash, etc.]

The method being used by Optimization:-Maximize here is the method=activeset of the Optimization:-LPSolve command.

We know that a global optimum ought to be found (if the problem is bounded, and it is...), as this is LP. It seems simply that the solver is just not recognizing that we'd like it to get more accuracy (more digits). I'll justify this supposition.

The solver being used is NAG's e04mfa, and that function in the NAG library does in fact accept an optimality tolerance option. In general the NAG library's optimization functions (chapter E04) use that to control how fine/coarse to compute an extreme point. But the Maple Library interface to that compiled external function, via LPSolve, does not admit and pass on any optimalitytolerance option.

If I use the Maple debugger to examine the arrays passed in for e04mfa's istate and clambda arrays then, following the hardware double precision call out to e04mfa for which the return value is ifail=1, some of the clambda values are small but of the wrong sign according to their corresponding istate values. The NAG documentation for e04mfa describes, in its Section 6, the case of a return value of 1 as being a "weak local" optimium, where it has assessed the lagrange multiplier values as being sufficiently negligible. See also its Section 5 descriptions of the return values for ifail, istate, and clambda. 

So, I believe what's happening is that the NAG solver thinks its current solution is optimal, because it's optimal up to the small magnitude and (potential violating) sign for the lagrange multipliers of the active variables. Now, down in Section 11.1 that documentation describes an Optimality Tolerance option, which "defines the tolerance used to determine if the bounds and general constraints have the right ‘sign’ for the solution to be judged to be optimal."

If I intercede where Maple is setting options for the call out to e04mfa, using an additional Maple call out to e04mha to set its "Optimality Tolerance" to 1e-9 then I get the expected global optimum -1.07676e-7 as the final objective and the expected solution point.

Moreover, if I use a bogus objective like OB+1e30  (where OB was the original objective) then I get a solution with one of Sw[4] or Sw[6] as 0.11 instead of the optimal 0.1, and that spurious -1.08216e-7 as the final objective value. But this bogus objective behaves like a constant. And the NAG solver reports taking just 2 major iteration steps, just like it does for the default double precision call that the OP is reporting to us. This is more evidence that the OP's example is illustrating that the external solver is returning immediately as soon as it finds a tight feasible point.

An ideal way to prod the external solver to continue iterating would be to allow an optimality tolerance to get passed through. But that's awkward to do.

Another way to get the better result from LPSolve is to increase Maple's Digits. The NAG documentation says that the default for "Optimality Tolerance" is 0.8*eps where eps relates to the machine epsilon (or its sqrt) in the case of hardware double precision. In the case of software precision the external solver uses 10.0^(-Digits) for that eps. This is why (apart from avoiding a crash) setting Digits higher allows the solver to find the true optimum, because doing so affects the default optimality tolerance. On my 64bit Linux I get the better result if I set Digits>=19 .

Yet another way to get the better result from LPSolve is simply to scale the problem so that the objective's difference (that we care about) is greater than the default optimality tolerance. On my 64bit Linux I only had to scale by a factor of (very roughly) approximately 2 orders of 10 to get the solver to obtain the better result. (This jives with the fact that the optimum's magnitude is about 1e-7 and forcing the optimality tolerance to 1e-9 also worked.)

I don't really understand the workings of the external solver used by LPSolve when method=interiorpoint. But my attachment also shows that it can be successfully prodded using either modest rescaling and some modest adjustment to the feasibilitytolerance option (which means something quite different to the solver), or by rescaling greatly.

Here's a sheet showing close to the bare changes to obtain the better solution from the Optimization package, in several of the ways described above (except the forced extra call to e04mha). It runs the same for me in Maple 17.02 as 2017.3, on 64bit Linux.
  LP_example_scaling.mw

If you call beta(0.4) outside of any plotting call the result is not a number but rather and expression containing the unassigned name b__sca which is just a single name.

The operator you assign to d is,

d := z -> t*b__sca/(1-z)

Perhaps you meant,

d := z -> t*b__sc*a/(1-z)

or,

d := z -> t*b__sc/(1-z)

If I understand you, then the name for that (or something effectively close to that) is "balancing".

That is offered by the command EigenConditionNumbers in the LinearAlgebra package, in the sense that it allows you to force it off or on. That command allows you to compute and return eigenvalues and associated condition numbers (and similarly for eigenvectors). Since that Maple command calls out to LAPACK function dgeevx this note may be useful.

See also this description. Note that in their inlined example the diagonal elements become 1.0 after balancing.

[edit] Technically balancing as mentioned above is comprised of permuting and scaling. And what you described is akin to the the scaling part.

The code to construct such Matrices can be quite short, using modular arithmetic.

Download detmod.mw

You don't need to load the deprecated linalg package. Matrix is different from matrix. The newer LinearAlgebra package is for Matrix, while the deprecated linalg package is for deprecated matrix or the deprecated array.

Maple is a case-sensitive programming language.

Submitting the word Determinant into Maple's Help system's search mechanism (search box) allows you to find the help page for LinearAlgebra:-Determinant command, and that includes notes on how to use it, as well as examples.

You could consider looking through the basic user manual, available in Maple's Help system by entering UserManual into the Help search box.

Please submit your future queries here as Questions and not as Posts.

If your working precision is too small then not all real roots of your degree 28 polynomial (that determinant, a polynomial in P) get their imaginary components resolved sufficiently close to zero as to be recognized as being purely real.

With Digits set only to 20 then only one real root gets resolved sufficiently (perhaps somewhat randomly).

You can see this a little more clearly by using fsolve on a complex box (rather than a real interval) and playing with the Digits setting.

At Digits=100 I get 28 real roots returned. Here I used Maple 2016.2, which you can upgrade your valid Maple 2016.0 to for free.

Stability_a.mw

I don't know of any 2D Input syntax that allows you to enter a Vector within a typeset radical and use the tilde to make that act elementwise.

I don't see that loading Units:-Standard is the problem here. What you had originally won't work even without that package loaded, AFAIK.

But you can do these:

Download Elementwise_Square_Root_a.mw

Eigenvectors, Eigenvalues, and Determinant, etc are commands in the LinearAlgebra package.

It sounds like you may not calling the commands properly. In order to access them you have to either load the package by first doing

with(LinearAlgebra):

or call them by their long-form fully qualified name, eg,

LinearAlgebra:-Eigenvalues(M70);

and so on.

In contrast, issuing M70^(-1) or 1/M70 dispatches directly to LinearAlgebra:-MatrixInverse.

Another possibility is that you got a result but since the inputs weren't floats then the result contained RootOf placeholders. I suspect that's not actually the problem, but it's not possible to know for sure because you haven't attached a worksheet/document that exhibits the problem.

Have you tried,

setmaple('a', 10)

a=10

You cannot get output like what you've described (ie. a mixture of upright text and 2D Output, and without separating commas) using the print command.

But you can still generate a procedure to assemble something which displays as output.

Download typeset_math_text.mw