@Rouben Rostamian  I'm curious to measure the time savings, if any, that come from this. It does use a lot of memory, because procedures returned by dsolve are huge. At the moment, I don't have the patience to wait it out. Those savings may be strongly influenced by whether the plot uses t-major or delta-major order.

Nonetheless, this trick is important because it's the only way I know to save these procedures (to disk perhaps) for use in another session, regardless of any savings; likewise for any instantiation that doesn't directly change a procedure's code (via subs).

@Rouben Rostamian You must've read and/or downloaded my code in the few minutes between when I first posted it, then noticed the same problem that you did, then posted a correction. The correction is only to the last line in Ndelta, where I do a weird-looking back-and-forth conversion of the extracted procedure to "%m" (Maple internal code storage format) string form. The internal format is necessary to capture the instantiation of delta. Exactly the same thing happens with a save/read back-and-forth to a disk file: The file must be put in ".m" form to capture instantiations that are not local to the procedure being saved.

So, it's definitely not a dumb mistake. And thank you for presenting me an opportunity to explain this weirdness.

I haven't looked into the details of your Question yet, but I have a question about your first sentence: What do you mean by "temporarily" in the phrase "temporarily difficult to be generated"?

That Maple Math mode in MaplePrimes produces horrific results due to the font used being nearly unreadable (somewhat as if handwritten very small and with a shaky hand). I'm glad that people seem to have mostly stopped using it.

@mmcdara A few clarifications for various things that you said above:

1. There's nothing special about delta in Maple, so there's no need to make it local; but doing so doesn't hurt either.
2. I don't think that it's possible to use odeplot to produce a plot that varies a dsolve parameter.
3. See my Answer for a trick for doing the plot3d.
4. Since there are no derivatives with respect to delta, the system can be solved (and plotted) as an ODE system. Perhaps in some more-formal mathematical context one might consider it a PDE system.

@pasty In recent versions of Maple (I think since Maple 18), a vector V can be converted to a list by [seq](V), and a list of vectors [V1, V2, ...] can be converted to a list of lists by [seq]~([V1, V2, ...]). While convert(V, list) is fast as you've noted, [seq] is a little faster, as well as being less to type.

@vv Vote up. I haven't tested this yet, but I'll assume that you have. So, if it works, it's definitely more elegant than my procedure. Your procedure relies on the ability of subs to return structures with not-fully-evaluated substructures. I was aware this well-known and well-documented feature of subs, but I hadn't thought to use it in this case. More often than not, the feature is a nuisance (but I'm not saying that it should be changed!) when one forgets to account for it. (Note, also, the relatively new subs[eval].)

I also like your placement of the multi-indices in a separate set, which is a more-elegant solution to the multi-index problem than my use of a keyword parameter.

Regarding `?[]`: I like that it's builtin, thus fast. (Another great feature is that it's overloadable on the left side of :=, but that's irrelevant here.) I have encountered problems using it in composed (@) expressions and elementwise (~) expressions (which I think I've posted about here, years ago)---problems which couldn't possibly occur were it not builtin. Thus, I tend to use the one-line non-builtin command index instead (syntax is identical to apply). If your formulation works, perhaps those problems have been corrected.

Nonetheless, I prefer your formulation with seq. I don't always prefer operator-style or functional-programming-style or non-alphanumeric coding. Brevity, readability, and efficiency are the ideals that I strive for.

Brevity has a much-more-profound effect on readability than I think most people realize. For example, the effort required to read and understand any procedure spaced out over two screens is I suspect at least double the effort required were the exact same procedure on one screen. Thus, spaces and blank lines must be used with care (care that you, VV, do take) and only when they profoundly enhance the readability. There is a disturbing trend in Maple coding than I've seen here on MaplePrimes of inserting an extreme number of spaces and blank lines, as if to say " You ' re   too   stupid   to   understand   this   if   I   didn ' t   space   it   out  . "

@AmirHosein Sadeghimanesh Although unassign can be used with multiple arguments, it's quite awkward to do in general because of the need to use 'unevaluation' on each entry. Thus, I'd use a loop, as in the following procedure:

RemoveTableIndices:= proc(
    T::uneval, J::set, {multiindex::truefalse:= false}
)
local j;
    if eval(T,1)::table then
        if multiindex then for j in J do unassign('T[eval(j[])]') od
        else for j in J do unassign('T[eval(j)]') od
        fi
    else error "table expected"
    fi
end proc
:
#Example:     
T:= table([2,4,6,8,10]);
        T := TABLE([1 = 2, 2 = 4, 3 = 6, 4 = 8, 5 = 10])

RemoveTableIndices(T, {2,3,4});
eval(T);
                     TABLE([1 = 2, 5 = 10])

RemoveTableIndices(T, `[]`~({1,5}), multiindex);
eval(T);
                           TABLE([])

It's still awkward, but so is almost everything done with unevaluated parameters.

I just want to make a small terminology point, which has no affect on how this Question is Answered or coded in Maple: What you have here is not an "algorithm"; it's simply a recursively defined real-valued function. If you want to consider some method by which this function and others similar to it could be converted to a non-recursive form, or a method to reduce the total count of arithmetic operations involved in its evaluation (recursive or otherwise), then those would be algorithms.

@tomleslie Thanks for checking!

So, the string conversion can be done by

ExMat2:= (x-> `if`(x::numeric, x, sprintf("%A", x)))~(ExMat);

Note that the format is %A rather than the more-usual %a.

@mmcdara Vote up, also. I think that this is the most-important thing that you said (not to say that any other part was unimportant!):

• The problem comes from the fact that setting Y :=1/2*X1 + 1/2*X2  does not give Y the attributes of a RandomVariable.

See my Reply to VV. This crucial problem which you've pointed out (and is the crux of numerous other short-comings of Statistics) could be easily solved in modern Maple if RandomVariables were implemented as objects and the arithmetic operators (such as * and + in the above expression) were overloaded with respect to that object. At the moment, I think that the majority of the work to code these objects could be done without touching the underlying Statistics package, which makes this work relatively easy.

@vv Vote up. However, I don't totally agree with your statement "Statistics is a modern package". Maple 16 (some 9(?) years ago) refined the concept of modules to include objects. RandomVariables should be implemented as objects, and Statistics (which is a heavily used package) desperately needs to be updated along these lines. 

@subzero I'm sorry to learn that it doesn't work for you. What Maple version are you using?  Although I'm not aware of using any of the numerous relatively new Maple features in that code, someone else here might recognize something. 

Please run this diagnostic: After entering the procedure code, give the command

trace(specdifforder);

Then define the expression that has the derivatives, and run at least one case that works and at least one that doesn't. There'll be a lot of hard-to-understand output (which'll nonetheless be very useful for me). Save the worksheet and post it here as an attached file. Files can be uploaded and attached by using the green uparrow on the toolbar. If you get an error message during the upload, just ignore it and proceed; it's likely that the attachment will work anyway.

@mmcdara You asked, rhetorically:

• But the things are not that simple...
  As changing 0.5 to 1/2 "works", one can ask ourselves  if, for instance, a*X1 + (1-a)*X2 still "works" when a is a rational between 0 and 1 (infering this doesn't work if a is a floating point number between 0 and 1)?

In the case of a any exactly represented number in 0..1 (whether rational or irrational), it is indeed "that simple": Maple will correctly compute PDF(a*X1 + (1-a)*X2, t) and the floating-point evaluators used by plot will be able to achieve the required precision over the whole interval.

@vs140580 So what makes this output any different from an ordinary Maple matrix? Why won't you give an example worksheet?