If you have a set of the form,

   {var1=..., lambda22=..., var2=..., var3=...}

then you can evaluate any formula at that "point" (set of equations of the form name=value).

In particular you can evaluate the simple formula of just lambda22 at that point.

This is especially useful when the equations are in a set, because the mechanism works regardless of the order of the equations in the set.

Download solve_eval.mw

There are several ways to accomplish this, so I'll give one of several alternatives.

One of the reasons to split off the "first argument" passed to plots:-animate is to provide a (sometimes easier) mechanism that having to use unevaluation-quotes. The original authors of plots:-animate recognized that avoiding premature evaluation would very often be wanted -- because the animating parameter would not yet have a numeric value -- and hence allowed a syntax that split the command from its arguments.

For your example, that same mechanism can handle it directly, as opposed to also utilizing unevaluation-quotes.

restart;
with(DynamicSystems):
with(plots):

num:=10*(s+alpha);
den:=s*(s^2+4*s+8);

animate(RootLocusPlot@NewSystem,
        [subs(alpha=a,num/den)],
        a=1..10);

f:=unapply(num/den, alpha):
animate(RootLocusPlot@NewSystem,[f(a)],
        a=1..10);

Of course there will be other examples where other flavours are easier.

A subtlety is that you do want f(a) or the subs call to evaluated up-front. It'd be (here, slightly) less efficient to have that be done upon each new value taken by the parameter a. The solutions discussed so far in this thread all do that part well.

The first step is to ensure that your procedure(s) can run under hardware double-precision mode, the simplest mechanism for which is by using the evalhf interpreter.

The plot3d command will attempt to use evalhf mode, but we need to make the TF procedure "evalhf'able". The following takes 4 seconds on my machine, while the original took 412 seconds.

Download tetrationFractal18_ac.mw

The next step is to ditch using plot3d as a mechanism for generating the data values, since we can avoid having to invoke evalhf being called for every x-y point. Instead we could write a single evalhf'able procedure that operates in-place on a predefined 2-dimensional Array (or Matrix).

While re-writing in that way, the coloring scheme could be revamped.

Further improvement would be to make that paralellizable (each thread operating on only a subrange of the x-values, say, but writing to the shared result Matrices), and compile'able under Compiler:-Compile.

note: In more recent Maple versions tetration can be attainted using the IterativeMaps:-Escape command, although that is with a fixed iteration limit (and not so easily with the fancy orbit check). I already had an example of that, but it won't run in Maple 18 since the package was introduced in Maple 2015.

After you assign a value to A the thing assigned to V still contains A.

If you then access individual elements of  V then evaluation occurs, and you'd get what you expect.

If you subsequently assign a different value to A the you could get a different result when accessing the relevant entries of V. (You might want to do this.)

But that evaluation isn't occurring when you print V.

You can map the eval command over V, or apply the rtable_eval command to V, to see the printing display all the elements after evaluation.  Eg,

     map(eval, V);

     rtable_eval(V);

Those both create a new instance of the thing, that contains the value you assigned to A rather than the actual name A. (If you subsequently assign a different value to A then these new instances aren't affected.)

The above describes "how" the behavior happens. Do you also want the (involved) explanation of the design decisions behind rtable evaluation rules?

Here are illustrations of the explanation above (of "how").

Download VectorCalculusQuestion_ac.mw

Yes, the parameter names generated by LinearSolve are indexed, and can be found by their type.

You can also programatically generate the base name, as a "new" (previously unassigned) name.

But I don't like your methodology of finding them, as it relies on each such name being present as an entry value (alone) of sol. That might be true as consequence of the LinearSolve algorithm, but it's an unnecessary weakness. And there are also unnecessary mappings and conversions.

You can choose the base name, and pass that to LinearSolve using its free option. And you can even programmatically generate such base names -- unassigned. That's pretty decent, and safe, control.

This alleviates the difficulty you've mentioned with not knowing what name like _t, _t2, etc, that will be indexed in the result. If you don't generate the base name using `tools/genglobal` then LinearSolve will. That's the same mechanism as LinearSolve uses.

So, generate the base name yourself, and pass it with the free option, and then you'll be sure to know what it is.

Download specindexLS.mw

You don't need to generate discrete data (and interpolate it), in order to obtain the smooth plot of the lambda operator.

The smooth plot of lambda is assigned to P2, below. You can use the so-called parametric calling sequence of the plot command to get the orientation for lambda(t) versus t.

   plot( [ lambda(t), t, t=0..1 ] );

You don't even need the discrete data here. I included it simply to overlay the point-plot with the smooth curve, to show you that they agree.

Download help2_acc.mw

Yes, as you mention you could freeze the function calls. The type system lets you target them quite well, and so subsindets is useful.

I don't like using frontend for this, since the set of things not to freeze varies by example. It's ad hoc. Consider what you'd need to do to handle,
   {x(0) + y(0) = 5, x(0) - sin(y(0)) = 3}
And now realize that it's much more straightforward to freeze specifically the function calls (of type constant) in question than it is to programmatically determine example by example what kinds of symbolic calls and subexpressions (depending on those function calls) which must be excluded from being frozen.

sys:={x(0) + y(0) = 5, x(0) - y(0) = 3}:

thaw(fsolve(subsindets(sys,And(anyfunc(constant),
                               Not(complex(realcons))),
                       freeze)));

              {x(0) = 4., y(0) = 1.}

sys:={x(0) + y(0) = 5, x(0) - sin(y(0)) = 3}:

thaw(fsolve(subsindets(sys,And(anyfunc(constant),
                               Not(complex(realcons))),
                       freeze)));

            {x(0) = 3.893939842, y(0) = 1.106060158}

Im not a big fan of the idea that these function calls (of type constant) should be considered as "variables". It's unclear what problems might arise, were fsolve to support this directly. Next might come unknowns x(a) and y(b), but then fsolve would need be careful to reject examples with unknown x(a) alongside bare unknown a.

Could you draw it twice, with two different padding sizes and the layout the same (so they are overlaid)?

The colors might be chosen with different chroma but similar intensity, so that the text labels are legible.

Download graph_twice.mw

The evalf (kernel builtin) extension mechanism invokes the extension procedure `evalf/XXX` even when the function call to XXX is a call to the local of that name.

Download evalf_extension.mw

I have a very vague recollection of reporting/complaining about this -- but that would be almost two decades ago. IIRC I was concerned with some cases of what happened (unexpectly, for me) under evalhf.

You can enter your expression using the inert operator `%*` , as Kitonum shows.

You can also enter your expression as a string, and use InertForm:-Parse (though it's trickier to target just the powers in question, if part of a larger expression).

And you can cobble together mechanisms to decompose. (Adjust or robustify as needed...)

And you can convert back to the active `*` form, in a few ways.

Download inert_pow_prod.mw

You should be able to use the results from the ifactors command, programmatically. (You can trivially massage its output into similar formats of your own invention.)

ifactors(725);

        [1, [[5, 2], [29, 1]]]

ifactors(1125);

         [1, [[3, 2], [5, 3]]]

ifactors(2048);

             [1, [[2, 11]]]

If I understand your sentences rightly then yes, the inner procedure that is defined in the body of the outer procedure will be recreated each time the outer is invoked/called, and this is unnecessary overhead (computational effort and memory management) that could be avoided.

If instead the procedure A were simply defined at a higher level than procedure B, then you should be able to call A from within B, under the lexical scoping rules.

You could also implement both A and B within the same module, if you would prefer some compartmentalization.

You could also make the outer procedure be the local ModuleApply of a module B, where A is another local procedure within that module. That would make B into a so-called appliable module, where the name B could be called with arguments.

Would you like examples of all this? Have you read the Programming Guide (esp. the section on modules?)

If you call the ZeroMatrix command without specifying its option

    compact=false

then (by default) the Matrix will be constructed with a special indexing function.

The effect of that is that the Matrix can only contain zeroes. (This is great for efficiency in some programming situations, since very large zero-matrices can take up little/constant memory.)

Much simpler is just to use the Matrix command instead of the ZeroMatrix command. The default fill-values of a call to Matrix are zero, and those don't have to be specified explicitly.

This is a guess, since you did not provide you code. It's almost always better to provide full code to reproduce. (The green up arrow in the Mapleprimes editor allows you to upload and attach documents. )

Download zeromatrix_edit.mw

For the 2D case here are two short versions. (They could be shorter still, but I wanted to show a few of the intermediate assignments.)

First, one using operators.

with(plots):
F:=(x,y)->4*x^2+9*y^2;
G:=[D[1],D[2]](F)(2,1);
display(arrow([2,1],G),
        implicitplot(F(x,y)=F(2,1),x=-4..4,y=-2..2),
        scaling=constrained);

And one using expression form.

with(plots):
f:=4*x^2+9*y^2;
fval:=eval(f,[x=2,y=1]);
gval:=eval(zip(diff,f,[x,y]),[x=2,y=1]);
display(arrow([2,1],gval),
        implicitplot(f=fval,x=-4..4,y=-2..2),
        scaling=constrained);

Both of those can be adjusted using various options for the arrow dimensions, etc.

And 3D versions can also be made. The 2D implicit plot can be raised to a level height on the 3D surface, or a single contour line can be specified at the specific height. See attached.

gradient_arrow_operator.mw

gradient_arrow.mw

I think that your example is interesting, since the "size" of the desired target expression is smaller than that of the original expression, using any of these as norm:
   length,  `simplify/size/size`,  MmaTranslator:-Mma:-LeafCount
So it seems reasonable to ask why the "smaller" form is not found directly by some flavour of call to simplify.

My compressor oracle found these two ways:

Download simp_radical_ex.mw

You probably already realize this, but you should not use the symbolic option of the simplify command if you care about results branch cuts and always being correct. However, your current example and desired target are equivalent. I just wanted to mention it, since you made it sound as if simplify(...,symbolic) might be generally applicable/valid.