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.

I took reciprocals (twice, naturally) in order to get op(2,X) and v into the exact same form. But the rest was not so bad.

It's always interesting when simplify (or the is command) requires extra help. [I will submit a Software Change Request, citing the examples.)

Download CubicRootsacc.mw

The line,
    combine(factor(expand(ee)))
will handle your expression, assigned below to ee.

If you have similar examples you might wish to restrict the combine by its exp option. If you have other examples where you don't want a blanket expand then you could target the original exp calls by using subsindets.

Download exp_factor.mw

Is it because you misspelled "typeset"?