Does anyone here know what precisely changed between Maple 15, where the rtable_eval is necessary, and Maple 2016, where it isn't?

@tomleslie

Suppose that you're at a "1-D math input" command prompt. Hit Ctrl-T. Now you're in "text mode". Now you can type ordinary formatted word-wrapped text as if you were in a word processor. This is good for putting extended formatted comments in your worksheets, much nicer than a bunch of lines beginning with #. You can also insert inert, formatted mathematical expressions into the text. When you're done with the text, hit Ctrl-J to get to the next command prompt.

@Mac Dude I didn't mean to imply that "putting it anywhere in the 'Maple 2015' directory" would work, although I can see how you might misread it as that. I only meant that putting it (or any other file) anywhere in that directory or any of its subdirectories isn't recommended. Indeed, it's disrecommended.

@Carl Love I have more time today, so I'll point out your syntax errors:

1. Curly braces {} can't be used instead of parentheses for algebraic grouping. So 2^(i) or 2^i are correct (and mean the same thing), but 2^{i} isn't.

2. Don't use the name of the function (aka procedure) in the function's header. So

f:= (x,y,i,j)-> ...

is correct, but

f:= f(x,y,i,j)-> ...

isn't.

3. A function definiton arrow has only one hypen. That is, -> is correct; --> isn't.

4. A procedure's return value is the value of the last statement executed by the procedure. So, the end of CreaF should be

     end do;
       V   #returns V
end proc;

rather than

end do;
end proc;

You can force a return from anywhere in a procedure, including its last line, by using the return statement.

5. This one is quite subtle, and I don't know if you'll understand this explanation. The "lexical" variables in a function are evaluated at the time the function is called, not when it's defined. In your case, j is a lexical variable because it's defined in CreaF and used in the lower-level functions g[n]. And the end of the loop, the value of j is 2^i. This is the value that j will have in every g[n]. The way to get around this is to use unapply:

g[n]:= unapply([f(x,y,i,j)], (x,y));

You also had four efficiency errors. These don't effect the correctness of your result, just the amount of time and/or memory needed to obtain it.

1. The first, and by far the most important, is that you shouldn't create a sequence, list, or set by iteratively appending to an existing sequence, list, or set. Unfortunately that is the natural way to try doing it. There are a great many ways to avoid this. My Answer shows one.

2. The values of your n and j are always the same. Thus, there's no need for both.

3. You never refer to previously computed values of g[n], so there's no need to save them. In other words, g[n] could be replaced by simply g.

4. The value of each item in the sequence V doesn't depend on the previous values. Thus the entire for loop can be replaced by a seq statement:

V:= seq(unapply([f(x,y,i,j)], (x,y)), j= 1..2^i-1);

The seq statement also addresses efficiency error 1, and obviously it also addresses 2 and 3.

Putting it all together, the following version of CreaF will follow your intended design (that it returns a sequence of functions):

CreaF:= proc(i::posint)
local x, y, j;
     seq(unapply([f(x,y,i,j)], (x,y)), j= 1..2^i-1)
end proc;

Simply saying "standard worksheet interface not run properly" isn't enough information for anyone to be able to help you. Could you provide more details, specifically, in what ways didn't it run properly?

@Vic To programmatically check for no solutions and print an appropriate message, you could do something like this

S:= solve(whatever);
if S = NULL then print("No solutions") else whatever else end if;

@Les Even if your constant k_ is correctly defined in a correctly placed initialization file, it can't be accessed as ScientificConstants:-k_. The accessing syntax is

ScientificConstants:-GetValue(ScientificConstants:-Constant(k_));

The best place to put your initialization file is C:\Users\Leslie\maple.ini. Putting it anywhere in the "Maple 2015" directory or any of its subdirectories isn't recommended, I believe, simply because that's not a place for personal files.

@Kitonum Vote up. For your first variant, the one with the gridlines, try adding option thickness=0. This'll make the gridlines thinner.

@mskalsi It makes a difference where your cursor is placed when you right-click to bring up the context menu to get to the Export menu. You want the cursor to be inside the imaginary bounding box of the plot, but not on the surface itself. If the cursor is on the surface itself, then that surface becomes the "selected" object which has a "context". The color of the selected object is lightened to indicate that it is selected. That lightened color survives through the exporting process, even though that seems ridiculous to me.

@max125 You wrote:

So it doesn't make a difference if you use {}  or [ ], when we define f,h.

No, {} and [] are different. A list, created with [], respects order and repetition; a set, created with {}, doesn't:

evalb( {8,9,6,7} = {8,9,7,6} );

     true

evalb( [8,9,6,7] = [8,9,7,6] );

      false

Can anyone recommend me a maple programming guide, for newbies?

You refer to "the following mapping", but I see no mapping. You refer to "the above procedure", but I see no procedure.

I agree with Tom: Please post your code. There's nothing that you've shown so far that would explain why they're printing in a column.

@JacquesC Ask on Stack Overflow instead. The question will very likely be rejected at math.stackexchange as being not math-related.

@Vic Iterator doesn't exist in Maple 2015. In Maple 2015, do

L:= convert(A, listlist):
J:= combinat:-cartprod(L):
['J[nextvalue]()' $ mul(nops~(L))];

@Marko Riedel There was one other change that I made that I didn't mention in my write-up. I made it at four places in your code. If L is a list and n and m are valid indices to it, then

[L[m], L[n]]

is the same as

L[[m, n]].

This can be extended to any number of terms. I don't think that this gives much time savings, but it shortens the code, especially when the name L is more than one letter.