@C_R You can make a first call to simplify with your expression, and trace `simplify/size` to see with what arguments that gets called.

Then you can restart (or forget as needed), and call `simplify/size` directly with the same argument that you ascertain from the first step. You can set printlevel before that.

I don't see how this would be effectively significantly different from what you are suggesting about some new functionality for a "local" printlevel option.

That second step would bypass printing of all the preliminary/final code executed by simplify, `simplify/do`, etc. And the second call could be terminated with a full color to avoid any typesetting details.

First step, from which all we want is to observe the arguments passed to `simplify/size`. (You could also pass the expanded expression, as a related example.)

restart;
trace(`simplify/size`):
simplify((a + b)*(c + d)+ (e + f)*(g + h)):
{--> enter \`simplify/size\`, args = (a+b)*(c+d)+(e+f)*(g+h)
{--> enter \`simplify/size\`, args = (_z1+_z2)*(_z3+_z4)
<-- exit \`simplify/size\` (now in \`simplify/size\`) = (_z1+_z2)*(_z3+_z4)}
{--> enter \`simplify/size\`, args = (_z5+_z6)*(_z7+_z8)
<-- exit \`simplify/size\` (now in \`simplify/size\`) = (_z5+_z6)*(_z7+_z8)}
<-- exit \`simplify/size\` (now in \`simplify/do\`) = (a+b)*(c+d)+(e+f)*(g+h)}

So now we know that we can just pass the expression itself to `simplify/size`, since we've now seen that's what happens when we call simplify itself upon the expression. (For other examples we might see that other arguments are passed at the inner stage of interest.)

Second step,

restart;
printlevel:=100:
`simplify/size`((a + b)*(c + d)+ (e + f)*(g + h)):
printlevel:=1:

Having said all that, I'll mention that -- personally -- I don't feel that printlevel is the most effective tool. I would always rather use the combination showstat/trace/stopat  with each of those being a crucial part of the mix. Others may feel differently, of course.

Here are two ways to get the value of S(t) from the solution returned by dsolve,numeric , where argument t has some numeric value.

You can actually use odeplot itself to get that other plot. Or you can use either way of using S(t) from the dsolve solution.

Download Paras31_2_ac.mw

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`);