@edahl If L is a list or a set, then L[] is its underlying sequence. To use a visual metaphor, it "strips off" L's surrounding brackets or braces. It's functionally equivalent to op(L) but is more efficient due to not needing to evaluate the symbol op and not needing to construct and pass an argument sequence for op. It's also two fewer characters than op(...), and it looks much cleaner to me in the code.

Caution: L[] functions like op(L) only if L is a list or set.

So, [x,y][] is the same as (x,y), but only the former is valid as the first argument to seq because the latter would be two arguments. This only works because seq's first argument is passed unevaluated.

Some may say that op(L) is easier to read or easier to understand. Those are garbage reasons. You might as well tell a music composer that they should write their notes as A-sharp, B-flat, etc., rather than use the standard musical notation. If you want to write clean, concise Maple code, you should learn the symbols.

@edahl The text editor vim has syntax highlighting for Maple. I think Emacs does also, but I've never used it. And Maple's "Standard" GUI interface has an embedded text editor which you can insert anywhere in a worksheet by using the menu command Insert -> Code Edit Region.

The following symbols have special meaning inside procedures, and are essentially reserved words (I may have forgotten a few):

• args: the actual argument sequence with which the procedure was called
• nargs: the numbers of items in args
• thisproc: pointer to the procedure itself, useful for recursion
• procname: the name by which the procedure was invoked including any attached indices
• thismodule: pointer to the module in which the procedure is embedded, if any
• _nresults: the number of operands to the left of := when the procedure's invocation is the right-side operand
• and these, which are all adequately defined on the help page ?using_parameters: _passed, _npassed, _options, _noptions, _params, _nparams, _rest, _nrest.

@waseem You're welcome. It's also possible to embed the betas in the plot with pointers to the curves, as in your example plot. This would require looking at the plot after a first draft is plotted so that you can decide on the placement coordinates.

Why do your command prompts keep switching between "F > " and "PW > "? I've never seen switching prompts.

@edahl Since you have Maple 16, also look up ?elementwise, which explains ~.

My guess is that will also work in Maple 16:

F:= (k::posint)-> assign([m||(1..2*k)] =~ [seq([dx||i, dy||i][], i= 1..k)]):

In a comment above, I forgot to say that using || is another way to guarantee that a variable is global. Using parse is similar, but not identical: It can grant you access to a top-level local from within a procedure. All of ||, cat, nprintf, and convert(..., name) are essentially the same with respect to globalness/localness.

Here's a procedure that shows 7 variations:
 

Download Locally_produced_globals.mw

@edahl Let's first get this working in your version of Maple, then I'll explain the code that works for you. My guess is that your Maple is older than Maple 13, which would make =~ not work. Regardless, try this, which uses zip(`=`, A, B) as an older version of what's now abbreviated as A =~ B:

restart:
F:= (k::posint)-> assign(zip(`=`, [m||(1..2*k)], [seq([dx||i, dy||i][], i= 1..k)])):
F(3), m||(1..6);

Look at these help pages: ?|| and ?zip. Actually cat is more flexible than ||. You're right that ~ is very similar to map. It can also replace zip, depending on the context.

@vv Okay, yes, I see that. The answer only applies to the OP's specific context. It's what I call an ad hoc answer. And I'm not saying that ad hoc answers are a bad thing! But I think that it's clear in this case that it doesn't really address the OP's overall Question.

@vv Yes, that works for that simple example, but it is awkward. If the procedure's author needs explicit access to the bound variable (which would be true in the majority of practical cases), it requires subtle "surgery" of f and/or r to get to the variable without accidentally evaluating it. Plus, there are numerous benefits of arguments being evaluated before they are passed.

Consider what you would need to do in your example if you were writing a simple alternative to plot rather than simply passing the arguments on to plot.

@vv No: Ignoring the restart for the moment, that x is not necessarily global either. It could also be lexical, module local, module export, or top-level local. There are two ways to guarantee that a variable is global: declare it global or prefix it with unary :-.

@Adam Ledger The issue that leads to the error is that the bound (or "dummy") variables of integration are being considered by NonlinearFit as if they were model parameters to be fitted. Hence it tries substituting numeric values for them. This issue is easy to fix by turning the model into an arrow procedure whose procedure parameters are the independent variable, x, followed by the true model parameters, beta and `ΔA`. This removes the error, but actually getting an answer is another matter.

@nm I'm sorry, but you've mistaken my ad hoc workaround Answer above as being more general than I intended. By ad hoc, I mean that it was intended to apply to the specific plot that you originally posted, on which the original scale for all three axes was 0..10. It should be obvious that that particular 0.4-factor adjustment cannot work for a general plot. And by workaround, I mean something that's meant to bypass a shortcoming or bug of Maple until better library code is written; I don't mean something that's intended to give Maple functionality equivalent to Mathematica in some area.

It'd be fairly easy for me to write a procedure to rescale the lengths of all the axes of a general plot to visually conform to any "box ratios" that you wanted. But rescaling the tickmarks of an unseen Maple plot is hellishly complex because a Maple programmer has no access to the tickmarks of the original plot when they are generated by the plot renderer in the GUI, which is the case for the vast majority of plots. In other words, a plot that a user sees on their screen has more information, more detail, than a Maple programmer has access to.

This is a shortcoming of Maple. Mathematica handles it much better. You'll get no argument from me about that.

@Carl Love You also asked if there was a way that was even more efficient than your first. Yes:

nFrames:= 10:
plots:-display(
   [seq(plot(sin(i*t), t= -2*Pi..2*Pi), i= 0..nFrames-1)],
   insequence
);

There are two separate simplifications that I've done: I replaced for with seq, and I eliminated the temporary variables frames and w (which become garbage that needs to be collected). When creating sequences, lists, or sets iteratively, for can be replaced by seq whenever

1. the element being created doesn't depend on any of the previous elements, and
2. the condition for ending the sequence doesn't depend on any of the previous elements.

The efficiency difference between your first and second methods is huge for large nFrames. The additional efficiency achieved by using my variation above is tiny by comparison.

@Adam Ledger Yes, your observation about the implication of the coprimality of j and k is correct. But even thinking about the simple concept of coprimality is already getting more complicated than is necessary for the problem.

@vv Yes, of course, his algorithm is fine (and perhaps asymptotically the best). It's only its implementation in Maple that's bad. In Maple, one shouldn't use sqrt on integers with a huge number of divisors, use is on large-number exact inequalities, or use arrow expressions containing function calls that are constant with respect to the arrow's parameters (unless one is sure that there's a remember table in effect). The first two of these are Maple-specific pitfalls; the third is something that a competent programmer in any language should foresee (though it's easy in Maple to overlook the fact that an arrow expression is a procedure like any other).

I was quite surprised at how brutal on my system and unstoppable his function was when applied to my data. And I tried several times, each time using smaller and fewer data.