@markweitzman

The name e is used for two variables in the scope of procedure F: It is a global used in the ODE, and it is the procedure parameter of F. These are two different variables that just happen to have the same name. In such situations, the global variable can be distinguished by using the prefix :-. I could just as well have used a different name for the procedure parameter, like ee. Then the statement could be Sol(parameters= [e= ee]), or Sol(parameters= [:-e= ee], or as you pointed out simply Sol(parameters= [ee]), (but not then Sol(parameters= [e])).

The algorithms for solving IVPs and BVPs are very different. As Mariusz's Answer shows, the BVP needs to be solved separately with a different approxsoln for each eigenvalue. On the other hand, the IVP only needs a single call to dsolve from which all the eigenvalues in any interval can be obtained. In a Reply below, I've updated the worksheet above, and I show how to obtain all the eigenvalues in an interval, and I actually do it and plot it for all under 100.

@Mariusz Iwaniuk For numeric BVPs, dsolve allows parameters in exchange for extra BCs. The BCs are counted at the syntax level, and it won't let you get away with giving the wrong number of them (even if perchance the solution satisfies an extra condition).

@_Maxim_ The nested context is what I would hope for. I can't now produce an example where the nested evalf doesn't work. I wonder if it's something that's been fixed in a recent version? I'm using Maple 2016 at the moment. Anyway, I withdrawal my first comment above: "evalf's nonstandard evaluation."

@Joe Riel wrote:

• It would be interesting to see the score of some of the spam that used to plague this site but, thankfully, no longer appears.

Okay, here's a great candidate that I deleted from this site a few minutes ago:

spam:= "The orthopedic treatment is identified with the musculoskeletal framework for illustrations bones .the orthopedic specialists utilize surgical and non-surgical medications. The non-surgical means the turn expire innate scatters and so forth. The ortho implies straight and paidion implies tyke. In days of yore the orthopedic treatment is basically utilized as a part of military reason little damage, and conceived Brocken and so forth. Arthroplasty is the principle part of orthopedic treatment and it is supplanted the musculoskeletal is supplanted. We can supplant the joints are knee, hip, bear, elbow, wrist, lower leg, spine, and finger joints .Epidemiology is another kind of supplanting of joint. be that as it may, it is confounded for underneath 18 years or more 80.After surgery take 1 month bed rest for in clinic. The orthopedic games solution is accessible on wherever on the planet. Furthermore, every games in your city. Orthopedic games drug is one of the particular callings. It is worked in gathering and they are likewise centered just the wellbeing of a competitor.":

seq(
   X = StringTools:-Readability(spam, method= X), 
   X = op(op([1,2,1,2,-1], eval(StringTools:-Readability)))
):
evalf[3]([%]);

[GunningFog = 15.5, FRES = 43.2, FKGLF = 11.1, ARI = 16.0, ColemanLauIndex = 21.2, SMOG = 13.4]

What kind of person would let someone who writes like that perform surgery on them?

@vv That's true for functions, but it's not true for basic arithmetic. For an example, try computing the residuals from the floating-point roots of a high-degree (50 or greater) polynomial.

@John Fredsted 

typeset can be used with caption just as it can be used with annotation.

@_Maxim_ Because of evalf's nonstandard evaluation rules, it doesn't work to do

evalf[d1](evalf[d2](e))

for d1 < d2, even though it's frequently what I want to do (to do a computation at high precision and only see a few digits of the result). You need to do it as

x:= evalf[d2](e):  evalf[d1](x);

which grates on my nerves.

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