@Kitonum Building a list in a for loop from a dynamic vector is a little bit faster than using a table or a remember table. Here are four ways to build a list in a for loop. There are several other possibilities for the indexing.

Download List_building.mw

Regarding _rest: This refers to arguments that are passed but not declared. It's equivalent to args[nargs+1..]. See ?using_parameters.

@Carl Love I ask again in case someone who knows the answer didn't notice the first time: What, if anything, is the difference between rtable_eval(A, inplace) and map[inplace](eval, A)?

Are you missing some parentheses in your formula? Do you mean

0.5*a*erfc(0.5*2^0.5*((-x+m1)/s1)) + (0.5-0.5*a)*erfc(0.5*2^0.5*((-x+m2)/s2))?

As you have it, m1, s1, m2, s2 can't be uniquely determined because common factors in the fractions can cancel. Besides, (-x+mu)/sigma looks normal; -x+mu/sigma doesn't.

Your Maple version is significant, but you didn't put it in the Question header. I believe that it is only since Maple 18 that Maple came prepackaged with a 64-bit compiler.

Please stop putting questions in the Posts section. Use the Questions section. Your first three have already been moved to Questions. To post a Question, click on "Ask a Question" on the top right of the page.

@Rouben Rostamian  Another clever one, which avoids the need to repeat x and `[]`~, is

plot(map2(`[]`~, x, [y1,y2]));

@ Thank you for the Reply. Yes, events are quite useful for stopping dsolve in situations that the programmer anticipates. Of course, in those situations, it is clear how the program, after stopping, can go on to return meaningful partial results. But I'm not interested (in this Question) in how to stop a program; rather, I am interested in how a program (any program, not just dsolve or odeplot)---which has been stopped via the stop button---can go on to return a result. If odeplot can do it, then other programs can do it as well, because odeplot is written in Maple---it's not builtin.   

@Rouben Rostamian  Thanks. The Maple 11 code for `convert/list` shows that when applied to a Vector, the relevant action happens on line 5 and is equivalent to my procedure CL2. In Maple 2015, the action is on line 15 and is equivalent to CL1.

@tomleslie The basic looping machinery of seq is several times faster than that of $. This can be seen with

restart:
CodeTools:-Usage([k $ k=1..2^22]):
memory used=96.08MiB, alloc change=32.00MiB, cpu time=750.00ms, real time=761.00ms, gc time=515.62ms

restart:
CodeTools:-Usage([seq(k,k=1..2^22)]):
memory used=32.00MiB, alloc change=32.00MiB, cpu time=203.00ms, real time=204.00ms, gc time=0ns

(Perhaps it's worth noting that the vast majority of the extra time for $ is due to garbage collection.)

However it's very easy to make a procedure f such that f(i) $ i= m..n runs significantly faster than seq(f(i), i= m..n). All that's needed is

1. f(i) should be a relatively complicated procedure that produces a relatively simple result.
2. f(i) shouldn't take significantly longer for symbolic i than for numeric i.

Here's such an f:

f:= proc(i)
local st:= time();
     while time()-st < 1 do end do; #Waste 1 second.
     i^2
end proc:

Now f(i) $ i= 1..9 takes 1 second and seq(f(i), i= 1..9) takes 9 seconds. This example is contrived, but solve fits the two criteria above. The key difference is that $ evaluates its first argument before numeric values are substituted for i and seq evaluates it anew for each value of i.

That answer about seq being thread safe makes no sense to me. $ is also thread safe, and I don't see why being thread safe would make something faster. The key seems to be that $ produces more garbage to collect.

@Rouben Rostamian  

Please execute my worksheet in Maple 11 and also include the result of showstat(`convert/list`) and report back. 

I doubt that there's been any relevant change to rtable_eval or the rtable evaluation rules between Maple 11 and Maple 2015. There has been a perhaps unintentional change in `convert/list`.  My CL procedures show that when the unevaluated variables are outside an rtable, they're like nitroglycerin---the slightest bump causes them to evaluate. When they're in an rtable, they're like nitroglycerin in dynamite---relatively stable.

The first two statements of procedure p need to be 

YP[1]:= Y[2];
YP[3]:= Y[4];

You have equal signs instead. This doesn't make it run any faster, but the results are total garbage without this change.

Regardless of the making the change, it gets stuck in an infinite loop at t = .27728275. The error message indicates that it thinks that this is a delay differential equation. I don't understand that. Anyway, you should be able to plot t = 0..0.27 with no problem. To get the error message, hit the stop button during the odeplot computations.

@nadjet 

You're only seeing Ex[1] because it's the only value set only one level deep in a for loop. By default, Maple doesn't show the results of statements nested two or more levels deep. If you want to see the contents of Ex and Hy, then after the loops do:

interface(rtablesize= 21):
Ex;
Hy;

@Mac Dude 

It's not the GUI. Any further manipulation of the result from convert at the command line (as opposed to in a procedure) in any GUI will result in the full evaluation of the variables. 

What does t = (t^1, t^2) mean? What does 1_\alpha mean?

@adel-00 

I said to add maxfux= 0 as an option to the dsolve command, not to the odeplot command!!