You've forgotten to load LinearAlgebra (or use the full name of Eigenvalues).

You can use Physics:-diff for x(t) as its second argument.

You had a problem in the second set (after restart) with the mapping of eval.

You incorrectly tried to use simplify as some kind of initializer/postprocessor to the Matrix constructor, by making it a final argument. That's not how the Matrix command works. You can wrap the Matrix call in a simplify call (but that might not even be necessary).

In your second set (after restart) you got muddled up trying to assign to A,B,Q.

SI_MODEL_ac.mw

Should the parameter r of periode be r::fraction so that it doesn't run away on integer input? (Or hard-code a trivial result...)

I notice that the inner list returned by periode can vary from that given by the following procedure, eq. for 1/13 .

F := proc(e::rational) local q,r;
  q := NumberTheory:-RepeatingDecimal(e);
  r := RepeatingPart(q);
  [nops(NonRepeatingPart(q)),nops(r),r];
end proc:

In the loop that forms TanSeq, there an unwanted call to tan around sinh(b*i + a).

You need the angles to be the sequence,
   arctan(sinh(a+i*b))

So TanSeq should just be the sequence of sinh(a+i*b) , given that you then apply arctan to each of those.

Those entries sinh(a+i*b) each (already, by definition) represent tan of an angle. You shouldn't be applying tan to them.

ps. You don't need a loop with iterated list concatenation. You can just use seq.

Equal_Incircles_theorem_ac0.mw

Your procedure phi has a conditional test against,
    type(k,even)

But that might not be what you intended. See comparison below,

Download test1_3ac.mw

So, having indicated that your phi might not be behaving as you expected, the integration results from trying the four combinations (all with m<>n) with each of m,n being assumed either even/odd might also bear re-examination.

But I'm not sure whether you are expecting results of zero. i.e. when integrating that phi2 variant under similar assumptions.

I suspect that you're asking how to achieve this programmaticaly, entirely in Maple.

You could try thing kind of thing:

with(FileTools:-Text):

WriteFile("f1234.mpl",
          cat(ReadFile("f1.mpl"),"\n",ReadFile("f2.mpl"),"\n",
              ReadFile("f3.mpl"),"\n",ReadFile("f4.mpl")));

You could also add other filler between the contents, if you'd like. You could also use seq and cat, if you have many files to conjoin and they're named in a numeric pattern.

The "\n" is to get a line-break between the end of the last line in a file and the beginning of the first line in the next file.

The student version of Maple has the same computational functionality as the regular version, if I recall correctly. (As far as I know, what differs is price and licensing.)

I'm not sure what you mean by "package" here, unless by that you mean version or licensing.

Here is one way to handle your example, if your goal is to regain the original factored form.

Download Ronan_simp_ex.mw

I personally like to see intercepts, and they can also be utilized here.

Also, I think that it's instructive to programmatically construct the equations from the Matrix/Vector data, if you've already shown such.

And this can get rid of implicitplot, which is a computationally inefficient hammer here.

Download linear_systems_icepts.mw

I could also have made the above two lines using a single call to the plot command. But I wanted to see them from intercept-to-intercept.

There are so many ways to do all this, including the construction of the equations.

The 3D case can be handled similarly.

The command plottools:-getdata can extract data from these, just like for usual 2D plots of curves.

Download pds_num_ex1.mw

You've mistakenly indexed things.

For example you have,
   Theta(t)[q]
instead of,
   Theta[q](t)

And similarly you have,
   diff(Theta(t),t)[q]
instead of,
   diff(Theta[q](t),t)

And so on. Note that Theta[1], Theta[2], Theta[3] are all names in Maple. They are indexed names, but can be used for function calls like Theta[1](t), etc.

And the initial conditions are done incorrectly. You can replace with D syntax to express the derivatives evaluated at 0.

I didn't wait for a symbolic solution. But a numeric solution using default method follows.

mrpicky_DE_syntax.mw

Check the edits for correctness.

The command,
   plottools:-getdata(p1)[3]
will return the 2-column Matrix of the data in the p1 plot.

You can then use the ExportMatrix command as one way to export it to a file with Excel-compatible format.

For example,

   ExportMatrix( "foo.xls", plottools:-getdata(p1)[3], target=Excel )

You should use add instead of sum there.

Also, if the Vector is assigned to m then utilize that name, not L.

In the current Maple version you could just call it as add(m).

For example,

Download Vadd.mw

The reason is that m[k] throws an error upon evaluation, where k is just an unassigned name. and m is a Matrix/Vector/Array.

The sum command will get its arguments (such as the reference m[k]) evaluated up front, which is Maple's usual evaluation rules for procedure calls. In contrast, the add command has special evaluation rules which delay the evaluation of first argument m[k] until k actually takes on the numeric values.

By the way, the following magenta error message is actually a URL. In my Maple clicking on it goes to this link, which contains an example and explanation, and the workaround using add. (note: Not all error message URLs go somewhere useful.)

Download Vsum_err.mw

Do you mean that you want the data in the userinfo message shown in the second attachment shown below?

In Maple 2020 it could be done programmatically as,

Download coordplot3d_ex1_M2020.mw

And in Maple 2024.0 in can be done as,

Download coordplot3d_ex1.mw

Issuing,
   showstat(plots:-coordplot3d);
can lead one to,
   showstat(`plots/coordplot3d`);

I'm not sure how much timing performance matters to you. If you only need a final plot then you might choose say 1e-4 or 1e-5 as target accuracy for that, and work backwards if reducing earlier working precision helps with performance. I don't know whether you need high accuracy, or faster timing.

Perhaps the following attachment has some useful bits. The re-usable procedures make it more straightforward to compute for arbitrary m-mu pairs. The plot3d command is invoked with a variable range formula (to respect a condition like mu^2>m, etc).

Your list N has about 50 possible values for mu. The "edge" that the 3d point-plot exhibits is coarse and uneven because the granularity of N doesn't allow all these found points to represent the same degree of closeness to the boundary of the inequality. The points themseleves directly provide only a very rough approximation.

But a style=surfacecontour 3D plot can get you a smoother boundary, with an even closeness for each m value. Naturally you could use another contour value, of your choice of boundary height.

And these procedures could be adjusted. A single dsolve call with two "parameters" might be used. Or an outer procedure might accept just one argument (m value), and then do root-finding (bisection or careful NextZero) for optimal mu value at boundary height. Etc.

Or you might interpolate your grid data programmatically, and then poll arbitarily or (with care for nested precision issues) find the boundary or implicit-plot; I didn't do so, but could it you'd like.

LoopError_acc.mw

Is this what you're trying to do: raise the 2D points in p1 to the vertical height (3D) given by the phi formula?

(This makes the 2D and 3D contour values match exactly, as well as allows the 3D plot to actually contain its data -- stored, and maybe a few other niceties of the 2D command.)

Help_3D_view_ac.mw 

Using your 2D contour plot and its colors,