@vv I think that a base-N conversion is more appropriate than inttovec. In the notation of the paper:

d = number of dimensions
N = number of subdivisions in each dimension
i = integer index
alpha = multi-index in [0..N-1]^d

Thus we have the following procedure:

alpha:= (N::posint, d::posint)-> 
   (i::nonnegint)-> 
      ListTools:-Reverse(convert(N^d+i, 'base', N)[..-2])
:

The ListTools:-Reverse isn't really necessary. I just included it to maintain strict adherence to the paper's notation.

It'd be very easy to implement that rectangle indexing scheme in Maple. If you just tell me the desired input and output formats, I'll do it.

@Carl Love My code above is quite dense (i.e., a short code does a huge amount), so some explanations are in order. I was just too tired last night to give them. First, I'll address the problems with your code:

1. Unfortunately, rhs and lhs can't be used on arrow expressions. There are some ways to get around this; however, I see no need to use arrow expressions at all to accomplish your purpose.
2. When things are put into a set, you can't control the order. In your case maintaining the order is important because you need to equate the correct derivative with the correct expression.
3. Your code relies on the use of the specific global variables x, y, and t. This is not an error, just a severe limitation.
4. Your code is limited to producing exactly two equations. This is an artificial and unnecessary limitation.

Now some explanation of my code:

1. The first argument is required to be a list to maintain the order. The algebraic means, essentially, to reject arrow expressions.
2. The second argument is a list of expressions of the form dependent_var(independent_var) = expansion_point.
3. Local F is the extraction of the functions (the left sides) from parameter P. Function, in this context, means an expression such as x(t); it doesn't mean an arrow expression or other procedure.
4. Local t is the extraction of the hopefully unique independent variable from the functions F.
5. Hopefully the purpose of the if statement and error message are obvious. If not, let me know.
6. diff~(F,t) forms a list of the derivatives of all the functions in F.
7. freeze~(F) makes a list of unique simple names which will replace the function names. This is what you used the simple names x and y for. There's no need to ever know what those names are; they are maintained in a table by the system.
8. =~ takes two lists and merges them into single list of equations. This is used twice.
9. The subs replaces all the function names in both arguments with the simple names, exactly like your first subs.
10. A [] after a list is to remove the brackets from the list. In this case it's needed to re-separate the S and P so that they can become the first and second arguments to mtaylor.
11. The map makes the mtaylor work on the entire list of expressions at once.
12. thaw undoes the effect of freeze. It does the same job as your reverse subs.

@Carl Love This does the same using the older Cartesian product command:

Vertices:= proc(P::list, Q::list)
local T:= combinat:-cartprod(`[]`~(P,Q));
   'T[nextvalue]()' $ 2^nops(P)
end proc:

Vertices([1,1,2], [3,4,5]);

@awass You wrote:

• I understand that you have reformatted the input to meet Maple requirements for the plot3d command. That is the difference between td and TD.

Yes, in that case (in my Answer), I'm using the list-of-three-operators calling sequence for plot3d, which is the fourth and final calling sequence listed at ?plot3d.

• However, the eval command is the magic which somehow prevents premature evaluation in this case.

No, my use of two-argument eval has nothing to do with premature evaluation. I used it to show you a better way to pick apart a dsolve(..., numeric) solution evaluated at a point. It's better because it refers directly to the desired objects rather than relying on their mysterious position numbers.

• I do not understand what is going on.

Consider the following two plot3d commands, which produce the same output---the unit sphere.

f:= (s,t)-> cos(s)*cos(t):  g:= (s,t)-> sin(s)*cos(t):  h:= (s,t)-> sin(t): 
plot3d([f(s,t), g(s,t), h(s,t)], s= -Pi/2..Pi/2, t= -Pi..Pi);
plot3d([f,g,h], -Pi/2..Pi/2, -Pi..Pi);

Both commands define the sphere as a parametrized surface in Cartesian coordinates. The first uses the list-of-three-expressions call sequence; the second uses list-of-three-operators. The second has no evaluation whatsoever in its arguments, so it certainly can't have a premature evaluation.

• The alternative solution you proposed using an if statement works equally well but I also find that a bit mysterious...

Both your original td and my original td require numeric arguments; they'll give an error message otherwise. So, evaluating td(x,t) before x or t have numeric values is premature, hence the term premature evaluation.

Consider the following trivial procedure, which could serve as a template for any of the vast number of Maple mathematical functions that accept both numeric and symbolic arguments (such as sin, cos, etc.):

sqr:= x-> if x::numeric then x^2 else 'sqr'(x) end if:
#Example usages:
sqr(3), sqr(x), sqr(y), sqr(x+3);
     9, sqr(x), sqr(y), sqr(x+3)

The magic is the 'sqr'(x) in the else clause. That's called returning unevaluated. (Unevaluated is being used as an adverb here, not a noun (i.e., there's not an object named "unevaluated" which is being returned).) The 'sqr' could be replaced by 'procname', that being a keyword by which a procedure may refer to its own name without explicitly using it.

• ...as well as your comment about "bound variables". Could you please explain that?

In all of the following examples, x and/or y are considered bound variables:

limit(f(x), x= 3);
eval(f(x), x= a);
int(f(x), x= 0..2);
seq(x, x= 1..10);
plot3d(x^2+y^2, x= -2..2, y= -2..2);

A bound variable is a variable whose meaning outside of the context in which it is used (and bound) has no relationship to its meaning within that context. In all the above examples, if x had been assigned a value immediately before the command, the result of the command would be an error, nonsense, or independent of that assigned value. Bound in this context is the past participle of bind; it is not the unrelated noun used in, for example, upper and lower bounds. See the Wikipedia article "Free and bound variables". Sometimes bound variables are called "dummy" variables. I disdain this usage because it trivializes one of the fundamental concepts of symbolic logic.

@Joe Riel A quick read of the code showstat(StringTools:-Readability) shows that the formula actually used by Maple (2016) is not as Samir reported but rather sqrt(...) + 3, exactly as you just suggested.

@_Maxim_ If you want to use bound variables within the plot3d call, it can be done by using an unevaluated return from td when it receives symbolic arguments:

ans:= dsolve({diff(y(t),t$2)=y(t), y(0)=a, D(y)(0)=0}, numeric, parameters= [a]):
td:= proc(x,tt)
option remember;
   if [x,tt]::list(numeric) then
      ans(parameters= [a= x]);
      eval([t, y(t), diff(y(t),t)], ans(tt))
   else
      'procname'(x,tt)
   end if
end proc:

TD:= (k::{1,2,3})-> (x,tt)-> td(x,tt)[k]:
plot3d(TD~([1,2,3])(x,t), x= 0..3, t= 0..3, labels= [t, y, `y'`]);

If you now want to use seq instead of ~, that'll be fine.

@nunavutpanther You are inferring way too much from my statement "It is very inefficient to create large sets by adding elements one at a time because every modification of a set requires the entire set to be moved in memory." What I mean is that if mon is a set with potentially thousands of elements and inside a loop you add potentially thousands more elements, one or a few at a time----THAT is what is very inefficient. Every time that a set or list is changed in any way, the entire set or list, no matter how long, needs to copied to new memory locations. Obviously in a sequentially processing digital computer (the vast majority of computers), the time required for that operation is proportional to the size of the set or list. (Also, the original copy needs to be garbage collected.) Maple tables and rtables (Arrays, Matrices, and Vectors) do not have this problem.

@taro Please execute these four examples. I hope that the output will help you understand what map is for.

map(`*`, [a,b,c], z);
map(f, [a,b,c]);
map(f, [a,b,c], z);
eval(%, f= `*`);

So, map cannot be used to convert a list into something else. If its second argument is a list, then its output will be a list.

@nunavutpanther If you want to create a list in the default set order with no repeats, then you can do that. Note that if L is a list or set then op(L) is equivalent to L[], so your line of code can be replaced by [{L1[], L2[]}[]]. If you don't care about order or repeats, then it's more efficient to simply make a list: [L1[], L2[]]. (Well, at least the creation of it is more efficient.)

HOWEVER, sets are always stored sorted, so checking whether an element is in a set is only time O(log(n)), whereas the same check in a list is O(n) where n is the size of the set or list---a huge difference.

@_Maxim_ Oh, okay. In that case, I withdrawal my comment about simplify.

The most disturbing thing about your example is that simplify returns 0.

Since it's not entirely obvious from the ensuing discussion, I thought that I should point out for less-experienced readers that Maple can ordinarily take the derivative of a definite integral with respect to a variable that occurs both in the integrand and the limits of integration, even if it can't do the integral. For example,

int(exp(-x*(t^3+t)), t= 0..x);
diff(%, x);

The case at hand is special because the integrand can't be evaluated at t= x.

@AmusingYeti It's a recent thing; it's been around a few years.

@AmusingYeti Yet sometimes the amount of allocated memory is reduced without restart: Sometimes you see that memory number on the bottom right go down, or you use CodeTools:-Usage and the reported "alloc change" is negative. I don't know how to force this to happen though.