As far as I can see, none of equations 1, 2, or 3 contain x (without subscript) on their right sides. Thus, the problem doesn't make sense to me.

@a_simsim Today a spammer made an identical copy of @nm's Post from the head of this thread, and you responded to it. In order to delete the spam, I needed to delete your Comment also. Please feel free to put your Comment here.

Nevermind. I just ran my test suite in Maple 2020.1, and I see that the fix has been released. Meanwhile, I think that that recent Questioner has deleted their Question.

@epostma Has your fix been released yet? I ask because this issue has been re-raised in a recent Question, albeit with a header marked "Maple 2019".

@Scot Gould I think that prime notation only works in 2D Input, which is fine. That's the reason that I didn't mention it.

@acer I wonder why you think that there might be a possibility of gaining some efficiency by separating the real and imaginary arithmetic. Is it that you think that you may be able to beat the C-compiler's ability to efficiently separate the arithmetic (does the default C-compiler not know the idiosyncracies of the processors that it generates code for?)? Or is it that the separation may allow for some symbolic simplification specific to Tetration?

@emendes Yes, in 1D Maple syntax, the only purpose of single forward quotes (I call them apostrophes, but that term doesn't seem to be used much nowadays) is to delay evaluation, sometimes temporarily (as is the case here) and sometimes permanently (as when they're used around a keyword argument).

They're always used in pairs, so they also act as parentheses that change operator precedence at the pure-syntax level (i.e., before the code is interpreted).

There are often many ways to delay evaluation; acer has shown one for this case. The quotes are the most-fragile way, but coming up with a more-robust alternative usually requires some creative thought, as acer's Answer shows.

@JonMcLoone Thanks for the code. From a quick glance, I'd say that it was competently and honestly written. I'd guess that I could tweak it a bit for efficiency, but without making major gains.

I've seen posted over the years numerous timing comparisons---made by third parties---where the Maple code was utterly incompetent, some of it scraped from my own ancient posts on Usenet and used out of context. Your benchmarking code is nothing like that. 

@vs140580 As Kitonum said, what you're asking for is usually called a Cartesian product, not a permutation with repetition, although it is possible to represent it as a permutations with repetition like this:

CP:= (S::{list,set}, m::nonnegint)->
    combinat:-permute(map(`$`, [S[]], m), m)
:

@opus64 It can't be called a bug in the usual sense of that word because it was designed to have that behavior, the design is documented (albeit quite tersely) at ?rtable_eval, and as far as I can see the actual behavior follows the design.

@Scot Gould This issue of when things are evaluated is something that only affects symbolic languages. You can't fairly compare this behavior to that of any nonsymbolic language. If the policy "evaluate everything fully, all the time" were adopted, the last example at ?rtable_eval shows what would go wrong.

That being said, this behavior can be quite annoying and difficult to understand, and only an expert can remember rtable_eval. There should be a package FullyEvaluatedRtables which would be suitable for small-scale, student, and desktop use. I think that I could write it in 50-100 lines of code. The internal representation would be lists of lists, because they fully evaluate. The ModulePrint would simply convert to an ordinary rtable.

@JonMcLoone Jon, I would like to see any of that Maple benchmarking code that you can provide. I'll give my opinion on whether it's competently written, and I'll try to rewrite it to be more efficient. I'd be particularly interested in the code used for the quadruple-precision matrix arithmetic tests shown at the bottom of https://www.advanpix.com/, mentioned in the ninth Comment in this thread. Those tests show Mathematica to be many times faster than Maple at these tasks. Does Mathematica have any special support for quadruple precision (as opposed to just general support for arbitrary precision)?

If you'd rather not post the code publically, use the Contact Author under the More... pull-down, and I'll send you my email address.

@vs140580 Here's the generalization of the seq method to Cartesian products of an arbitrary number of factors:

CP:= (S::{list, set}, m::nonnegint)->
local k, i, j:= i= 1..m;
    [value](foldl(%seq, [k[i] $ j], (k[i]= S) $ j))
:

If you only want to see certain iterations, you could do something like this:

L:= CP({0, 1, 2}, 10): #end with a colon!
L[2100..2199];

@AHSAN You're wasting my time. Give all the details of what you want at the start. Now you have 5 x values and 4 F values. Do you need me to tell you that that doesn't make sense? If not, then why haven't you corrected it already?

@AHSAN So what are the x-values then? Certainly not the 1, 2, 3, 4 that I used.

@vv Yes, you're right: I meant to write what you wrote. The way I wrote it, there is a small inefficiency due to a one-step recursive call. Thanks for pointing it out.