@adel-00 That expression determines the coefficients for a system of linear equations, and you're correct that those coefficients are real; but that expression doesn't specify the rhss of those equations. The rhs of ode1 contains the subexpression x^(2-alpha) (where alpha=0.2 is constant). When you evaluate this for x < 0 (which you do do to get the rhss of your linear equations), you get nonreal values.

@adel-00 The true solution of the ODE is in general complex for negative x. If you do the dsolve without initial or boundary conditions, you get

y(x) = 1259244087*x^(19/5))/14440000000 + 19*x^2/20 + _C1*ln(x) + _C2

@acer I totally agree with you that using a remember table doesn't help in this situation, and I had even expressed my skepticism about it in a Reply to Rouben. I will edit my Answer to reflect that.

My original enthusiasm for it was motivated by the fact that if a table were desired, the mechanism required to create it is totally non-obvious.

@lcz I'm not sure whether your first response in this thread indicates that your original Question requires no further Answer. Is that true?

@lcz No worries (a common colloquial expression that can mean "there's no need to be sorry")^[*1]_. I'm well aware that many (perhaps most) users here don't have English as their first language. I only point these things out when there has been (or there is likely to be) confusion. I am happy to provide any help that I can with English usage, Maple usage, general math, computer science, and other subjects.

And I wouldn't exactly call what I provided in this case a "correction" because even indefinitely seems inadequate for this particular situation. I was trying to describe why "temporarily" is certainly incorrect, as well as confusing.

[*1] "No worries" is perhaps better known and older from a colloquial Jamaican dialect. In that case, the meaning is somewhat different. The present usage comes from colloquial Australian.

@tomleslie The reason that we continue to discuss numeric methods for the solution of this problem is that producing plots that use varying parameters of an ODE system (whether or not those parameters can be included in dsolve's parameters option) is an important problem and a very common subject for Questions here on MaplePrimes. You've Answered many of those Questions yourself. Unless the system is linear (as is the case here), the likelihood of the analytic approach working is practically nil. So, while your approach is indeed quite timewise efficient, unless the system is linear, it's not likely worth the effort to make an analytic attempt for a practical problem (rather than a textbook problem).

@lcz Possible adverbs to use instead of temporarily are indefinitely, currently, presently, at the moment, or at this time. The adjective temporary or its adverb temporarily can only be applied to a period of time that is definitely known to be finite although its exact length is perhaps unknown. Considering the subtlety of this distinction, it was suprising to me how confusing "temporarily" was in your context. Of the five alternatives that I presented, indefinitely is the only one that emphasizes the distinction between "known to be finite" and "not known to be finite".

@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.