This concept can be easily generalized to rtables of any number of dimensions, and it can be done in such a way that all previously covered cases are handled with the same syntax.

#The optional fourth parameter d is the dimension along which
#to perform the operation.
InsertSlice:= proc(A::rtable, V, p::posint, d::posint:= 1)
local D:= [rtable_dims(A)], n:= nops(D), L:= (..)$d-1, R:= (..)$n-d;
   ArrayTools:-Concatenate(
      d, 
      A[L, ..p-1, R], 
      `if`(
         V::rtable and rtable_num_dims(V) < n,
         ArrayTools:-Alias(V, 0, [D[..d-1][], 1, D[d+1..][]]),
         V
      ),
      A[L, p.., R]
   )
end proc:
   
A:= Array((1..3)$3, rand(-9..9)):
seq(A[..,k,..], k= 1..3);
                   [-1  -4  -8]  [-8  -3  -2]  [-7  7  -9]
                   [          ]  [          ]  [         ]
                   [ 4   1  -4], [-1  -1  -7], [-2  1   4]
                   [          ]  [          ]  [         ]
                   [ 9   5   0]  [-1   8   5]  [ 8  2   2]
M:= Matrix(3$2, rand(-9..9));
                                   [ 9  -1  -5]
                                   [          ]
                              M := [ 3  -9   8]
                                   [          ]
                                   [-1  -1  -6]
B:= InsertSlice(A, M, 2, 2):
seq(B[.., k, ..], k= 1..4);
            [-1  -4  -8]  [ 9  -1  -5]  [-8  -3  -2]  [-7  7  -9]
            [          ]  [          ]  [          ]  [         ]
            [ 4   1  -4], [ 3  -9   8], [-1  -1  -7], [-2  1   4]
            [          ]  [          ]  [          ]  [         ]
            [ 9   5   0]  [-1  -1  -6]  [-1   8   5]  [ 8  2   2]
#An example with a "thick" slice:
M1:= Array(1..3, 3..4, 1..3, rand(-9..9)):
seq(M1[..,k,..], k= 3..4);
                         [ 8   2   6]  [-3   4  -6]
                         [          ]  [          ]
                         [-8  -1  -5], [-1   8  -9]
                         [          ]  [          ]
                         [ 5  -4   7]  [-2  -2  -4]
B1:= InsertSlice(A, M1, 2, 2):
seq(B1[.., k, ..], k= 1..5);
     [-1  -4  -8]  [ 8   2   6]  [-3   4  -6]  [-8  -3  -2]  [-7  7  -9]
     [          ]  [          ]  [          ]  [          ]  [         ]
     [ 4   1  -4], [-8  -1  -5], [-1   8  -9], [-1  -1  -7], [-2  1   4]
     [          ]  [          ]  [          ]  [          ]  [         ]
     [ 9   5   0]  [ 5  -4   7]  [-2  -2  -4]  [-1   8   5]  [ 8  2   2]

@Kitonum It's mentioned in ?solve,details that solve ignores assuming real even if you use the option useassumptions. Thus the solutions need to be verified, which, in this case, is very messy if you want to do it exactly, but not bad if you're okay with a decimal approximation. Your three solutions are indeed correct; I'm just saying that they need to be treated with some suspicion at first.

@tomleslie Sadly, the ~ operator was added in Maple 12 or Maple 13. But that's easy to work around by using map or zip.

@das1404 David, I added a significant amount of new material to my Reply "eval" above, so you should probably read that again.

@tomleslie I suspect that the most-significant performance penalty of MutableSets will be making equality comparisons.

@JoshuaLeiter Thanks. My only regrets are that your one line of code turned into my 11 lines, plus comments, and that this happens so often in 3-D plots. There are so many possible anomalies. Yet it's just a pair of algebraic functions. It took me so many tries, and I've been doing this for many years. There should be some more fundamental ways to correct these. What I've learned today: Strive to use exactly one expression (or one parametric list of three expressions) for each connected component of the surface.

@9009134 I didn't ignore your problem. I worked on it for about two hours without making progress that I thought significant enough enough to report. I was neither able to do it nor prove that it couldn't be done. I suspect that some other correspondents here had the same experience. Perhaps if we detail our experiences, some collaboration will lead to progress.

I recall being able to algebraically eliminate one of the three dependent variables. I thought that that was odd, but not necessarily a bad sign.

I'll see if I can find the notes that I made about it. Recovering unsaved worksheets after a Maple GUI crash is iffy.

@das1404 Please place your Replies after the post that they apply to. If you don't, then we need to move them because having them misplaced makes the thread difficult to read through in the future.

I guess that you're thinking that evalf and eval are alternatives (perhaps because of the similar names?). They are not; they are independent, and sometimes you'll need to use both. You use evalf to convert expressions that are not decimals into decimals. Unlike at-wise eval, it's not used to extract expressions, nor does it need to be applied to expressions that are already decimals. So adding evalf to the eval in this case would be superfluous (although harmless) because the numeric parts are already decimals. So, eval(E, S) could be changed to

evalf(eval(E, S))
or
eval(evalf(E), S)
or
eval(E, evalf(S))

They're all similar, although the order that floating-point operations are done can affect the accuracy (sometimes in very surprising ways). If an evalf were necessary, I'd generally use the first of the above because giving evalf a larger perspective may allow it to make adjustments to improve the overall accuracy. The paradigm is compute first, then round; rather than round first, then compute, then round again.

@acer I noticed the uneven grid lines and didn't think much of it. Now, I realize that of course it's due to the overlapping surfaces. Since you consider the uneven grid lines to be a visual anomaly, and since I'd rather not have overlapping surfaces (because it's a computational anomaly if not a visual one), I decided to also separate the plotted expressions based on the sign of c. This also avoids a doubled (dark) band in the middle.

Explore(   
   plot3d(
      `if`(
         c >= 0, 
         sqrt(z^2+c), 
         [[abs(sqrt(z^2+c)), theta, z], [abs(sqrt(z^2+c)), theta, -z]]
      ),
      #must be theta first, then z: 
      theta= -Pi..Pi, z= `if`(c >= 0, -sqrt(8), sqrt(abs(c)))..sqrt(8),
      coords= cylindrical,
      grid= [50, 36], #much better option than numpoints 
      #'A 'view' independent of c stabilizes the axes' lengths for Explore: 
      view= [-2..2, -2..2, -sqrt(8)..sqrt(8)],
      thickness= 0 #Use thinnest gridlines available.
    ),
    #Decimal points are needed for float Explore parameters,
    #lest they be treated like integers:
    c= -1.0..1.0 
);

@acer I've tried about 10 variations in cylindrical coordinates, and they all had anomalies (different anomalies), so I gave up. The Answer that you saw was only up for about one minute before I spotted the anomaly, so you got it at just the right time.

I just had a new idea, so maybe there'll be another Answer in a few minutes.

@das1404 

If E is any expression, possibly containing some variables V, and S is an equation or a set or list of equations, possibly containing some equations of the form v = e where v is any variable in V and e is anything at all, possibly a number, then the command

eval(E, S)

will return the result of substituting into E the appropriate e for every v which appears both in E and on the left side of an equation in S. The command actually allows a bit more generality than that, but what I've said already is probably more than enough for a first lesson on eval.

So, applying this new knowledge to your situation:

L3:= selectremove(hastype, L2, nonreal(float));
LR:= L3[2]; #the ones with no imaginary parts
for S in LR do
   print( eval(V, S), eval(alfa, S) )
od:

As you go to read the help page for eval, let me warn you that unfortunately there are two totally unrelated commands in Maple named eval and they're both described on that help page. (And the paragraphs that apply to each are not clearly separated.) The only way that they can be distinguished is by their arguments. If there's one argument or two arguments with the second being a positive integer, then it's the older eval (not the one that I used above). If there's two arguments with the second being an equation or a list or set of equations, then it's the one that I'm talking about here. Sometimes this form is casually referred to as "two-argument eval" even though the other form may also have two arguments. So, coining a new term, I'm going to call the form that I'm talking about here at-wise eval (because it evaluates expressions at values), and the other form level-wise eval (for reasons that I don't want to say because they're too esoteric for this discussion). So, as you read that help page, once you figure out which paragraphs are about the level-wise eval, you should ignore them. You need at least a year of solid experience with computer algebra to understand them. On the other hand, the at-wise eval is one of the fundamental commands that a beginner should learn on day one.

There's also a command Eval which is closely related to at-wise eval. I'll call it inert at-wise Eval if I need to talk about it (which I don't feel like at the moment).

You are right to be surprised that applying a numeric index to a set (which, of course, has no mathematically prescribed order) is allowed in Maple. Therefore, you'd probably not be surprised that it's almost always (but not 100% always) a bad idea to make use of that fact. Those sets of course must be stored in some order by Maple, and Maple 7 ensures that the same set will always be stored in the same order in a given session. (And modern Maple ensures that that order is consistent between sessions.) It is because of this Maple-prescribed order that occasionally it's useful to apply an index to a set.

There aren't many times in Maple when it's necessary or useful to convert some mathematical object into a string so that you can access some proper subset of it to convert back into some other mathematical object. It happens occasionally (mostly when you're writing programs that themselves write programs), but there's usually a better way. So, if you feel the urge to do that, it's probably time to ask here. Of course, there's no harm in learning how to manipulate strings in Maple! That can be very useful.

@Kitonum The OP means that he wants to plot his original functions correctly. Getting a technically correct plot of functions that have been corrupted with Re was not his original intention.

Oops, I see that you have Maple 7. I don't think that it has selectremove or multiple assignment. But check if it has select and remove. If it does,

LI:= select(hastype, L2, nonreal(float));
LR:= remove(  ditto );

If it doesn't, then

LI:= [seq(`if`(hastype(s, nonreal(float)), s, NULL), s in L2)];
LR:= [seq(`if`(hastype(s, nonreal(float)), NULL, s), s in L2)];

@digerdiga The values of frozen objects are stored in the remember table of thaw. So, you can do

thaw(`freeze/R14`);

etc.

NM, Stefan V has said everything that I was going to say as a Reply, and he's included a nice explicit example of exactly what I meant when I said "Even if S[k]:= x were allowed, after doing it, it wouldn't necessarily be true that S[k] = x or that nops(S) was the same as it was before. Those two facts alone make S[k]:= x too weird to consider using."