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

Using Maple 18.02, since that's the version in which your attachment was last saved.

Download total_PE_ac.mw

You can insert a new execution group after the current line using either the keyboard shortcut Ctl j, or the main menubar item,
   Insert -> Execution Group -> After Cursor

The keyboard shortcut for inserting before the cursor is Ctl k.

The keyboard shortcut for splitting an Execution Group at the current cursor position is the F3 key.

You can see a listing of the shortcuts on MS-Windows by looking at the Help page for topic
   worksheet,reference,hotwin
Here's the link to that in the online Help (version Maple 2013, not your Maple 18, but these particular shortcuts are unchanged).

For "Mac" (OS X) the variants are shown on the Help page with topic,
   worksheet,reference,hotmac
For example, Cmd j and Cmd k

That can be attained directly by Matrix indexing, eg.

Download matrix_indexing_ex.mw

If I understand the question correctly then here are two more ways, using reasonably terse syntax.

Download mvdivelem_ex.mw

Those don't use any functionality new to only recent Maple versions.

ps. If you haven't already assigned the number of columns of Matrix A (here, the value 4) to some name, then it can be obtained as op([1,2],A) .

This is fiddly, but...

Download ts_negmspace.mw

Here is an example that you might find useful.

I'm using Maple here. I don't understand what you might want that's make it different for Maple Flow.

And I'm not sure what generality you're after.

Download comp_ex2.mw

I'll mention that I'm not really sure that I've understood you precise goal. Here is a variant that might be closer to what you want.

Download comp_ex2b.mw

Yet another possibility is that all your shown operators are actually starting off for you as just expressions, and you're trying to figure out how best to turn it all into the final (partially composed) operator.

For instance, you originally showed R as,
   R := T -> exp((y-1/2*x)^(1/3)-(y+1/2*x)^(1/3));
where the parameter of that operator is T, which is not used within the body. As it stands that doesn't make syntactic sense. I can't tell whether you want that attempt to be fixed or to be accomodated.

Yet another possibility is that you're mostly trying to get (expressions or) operators to be legible when displayed. In that case you might be interested in commands such as PDEtools:-declare, so that the functional dependence of x & y upon T is visually suppressed. 

Please let us know what you're really after.