Here are three straightforward ways to map that operation across your ptlist,

   (u->TransMatrix.u)~(ptlist);

   map(u->TransMatrix.u, ptlist);

   map[2](`.`, TransMatrix, ptlist);

Are you trying to accomplish something like this, using the command Physics:-diff to differentiate wrt the function call u(t)?

note: what you showed in plaintext is not valid 1D Maple Notation code, so I've guessed at what you might have intended. Adjust as needed.

restart;
H:=(y,u,t)->y(t)^2+u(t)^2+1/(2)(x(t))^(4) +(`∂/∂ x`)(V(t))*u(t):

Physics:-diff(H(y,u,t), u(t));

   2*u(t)+(`∂/∂ x`)(V(t))

H:=(y,u,t)->y(t)^2+u(t)^2+1/(2)(x(t))^(4) + Diff(V(t),x)*u(t):

Physics:-diff(H(y,u,t), u(t));

        2*u(t)+Diff(V(t),x)

You haven't shown us your actual expression. But you might be able to temporarily substitute for x-x0, then collect, then resubstitute.

Btw, your attempt using abs(x-x0) works as a specialized case of collecting wrt just abs.

Download collect_algsubs.mw

The results from implicitplot3d often look clunky, and sometimes edges inaccurately appear rounded, unless the sampling grid option is set so high that the GUI becomes sluggish when they are manually rotated, etc. It is an inefficient mechanism. It is a poor choice for handling this example.

I prefer to use plot3d when possible. Or, in this case, the tetrahedron plotting command can be used and produce an even more lightweight result.

Both of those can produce a much better rendition here than does implicitplot3d. 

Download tetra.mw

Unfortunately shadebetween cannot handle a variable range end-point. Hence my alternative was to fill a plot3d of y-1 and then raise by 1.

Using seq is not the most efficient and convenient way to do this.

But you asked about it, so I'll answer the question as given.

In later versions you could do it in 1D Input as,

  seq(seq( if a[i,j]<0.2 then a[i,j]:=0 end if,i=1..20),j=1..20):
  a;

Otherwise you could do it as,

   seq(seq(`if`(b[i,j]<0.2,assign('b[i,j]',0),NULL),i=1..20),j=1..20);
   a;

There are other variants.

Here are two straightforward ways, using either diff or the D operator.

(You might also augment the original pde system with a new equation for the desired derivative, but I'll leave that.)

Download Hw-02-01_problem_ac.mw

It's worded like that because only some tasks can be better done much more efficiently with the functional forms. It's not always the case.

Do-loops are not inherently inefficient. In fact they can sometimes be outright useful in writing very efficient code, eg. if one is trying to write procedures that can be run under evalhf or Compile.

I don't know your definition of "Generally speaking". Sometimes it seems more common for people to write inefficient code using loops -- though of course doing so is also possible with functional programming equivalents.

There are some common tasks that are often done poorly with loops. One class of such involves unnecessarily higher order computational complexity (often memory-space complexity, but sometimes time), eg. O(n^2) verus O(n), etc.

Would it help if you were shown examples of some common efficiency anti-patterns?

Here's one example. The procedure p3 below is inefficient in memory use and (partly due to ensuing memory management) time cost, and scales up very badly wrt size, but it's a code form that is often seen. I've even seen its poor technique in textbooks.

Download loop_functional.mw

While alternative p1 is by far the most efficient of the three above, its functional technique is not always very convenient without some structural code changes. Sometimes it's convenient to perform a given operation in a loop (say, because the operation is in stages and a handy procedure isn't yet written to do each one individually). The alternative p2 generates the same result too, and uses the same kind of loop structure as p3, but avoids the higher space complexity and ensuing memory management time cost. And while p2 doesn't scale up as well as p1, but it does do much better than p3.

The main problem with p3 is not the loop per se; the problem is the repeated augmentation of lists (an immutable data structure).

So why do people so often code such tasks in the manner of p3? Perhaps it's because it's approach is simple to understand and remember. Loops are more straightforward to debug. And using a table introduces another flavor of data structure -- ie. more details to remember.

Do loops tend -- more "generally" than do functional equivalents -- to be used for code with an innappropriate computational complexity? Maybe.

But it's also possible that a reason for seeing more inefficient loop code is that loop code is more common than functional equivalents; I doubt anyone's studied the proportions, for Maple.

And it's possible to write suboptimal code with a functional programming approach. Unnecessary collectible garbage might get be produced by performing an unnecessary number of separate mappings, eg. with L indexable,
    f~( (L -~ 3.0)/~11.0 )/~ 5.0 + sin~( f~( (L -~ 3.0)/~11.0 )/~ 5.0 )
or what have you.

You could call collect on an expression containing placeholders for names nu[1],nu[2],u[1],u[2],u[3], and then subsitute for those placeholders.

collect_complete_ac.mw

Here is one way, using implicitplot since you had that.

(It might be possible to produce a nicer surface directly with plot3d, say, instead of generating a collection of polygons as implicitplot does.)

Download Projection_ac.mw

I'm supposing that you wanted the patch projected only onto the upper part of the sphere, where z>0. You could change that, to use -sqrt(...) instead. Or you could generate both. Eg, Projection_acc.mw

Following dharr's comment about the piecewise, a dsolve-numeric event could also be used.

min_problem_ac.mw

Alternate kinds of events are possible.

Yes, the terms are taken in the order in which they are currently stored.

Download coeffs_ord.mw

Note that if the order of terms didn't matter then there'd be less point to the optional side-effect assignment to the 3rd argument 't'.

If you'd prefer you could use the CoefficientList command, for which the order is fixed and only the coefficients returned (because the order of the terms is implied). There is a cross-reference to that command from the Help page for coeffs.

ps. These aspects have not changed since Maple 2015.

Here is one way to handle your example,

S := "124e34e243e45e56e76f34e45e23ea12e98e34e43":

parse~(StringTools:-Split(S,cat(seq("A".."z"))));

     [124, 34, 243, 45, 56, 76, 34, 45, 23, 12, 98, 34, 43]

In Maple 2023.0 the edges themselves are represented as CURVES plotting substructures. That's different from, say Maple 2015.

That means that the edge lines will always be rendered on top of the arrow heads (which are POLYGONS substructures). You probably don't want to see such an effect; it's not pretty, if the colored arrow head appears below a differently colored edge line.

One possible approach is to split the edge lines at the arrow head, using some undefined value(s).

You could modify this to change all/several arrows at once.

Download changearrowhead0.mw

This whole approach depends on the fact that the order of the POLYGONS and CURVES substructures match. That might not be set in stone for the future...

I just wrote this off the cuff. It's not mint-clean (option names unprotected). I didn't test thoroughly.

You have fasteners as a list of Vectors.

You are trying to map some mapped operation (that itself maps across the Vector entries) across the list. That can be done using map or elementwise operations with a nested syntax (including in 2D Input mode).

Your examples could also be handled by targeted substitution (evalindets).

[Sorry, my worksheet fails to display inline here right now.]

Download elementwise_ac.mw

You could construct an interpolating function from the x-y-z data, which could compute a z-value for any x,y pair within range.

Then you can make any usual kind of plot, and add coloring, options, etc.

For example, using the very small collection of data originally provided, see below.

I forced 20 contour values, but you could just as easily specifiy the contour values in steps of 100 ( ie, seq(...,100) instead of seq(...,numelems=20) ).

Download interp_cont_data.mw