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

@EvilDuncan The answer changes for me. Using HeffR, I have the eigenvalues expressed as the roots of a relatively simple polynomial. That is, its coefficients are relatively simple compared to the algebraic functions that were input. You can also use specific values of x as in Eigenvalues(eval(HeffR, x= 1)).

Can you post an executed worksheet that shows them unchanged?

Ultimately, you're going to need decimal approximations for these eigenvalues, right? When you get to that stage, you'll get more-accurate results from

Eigenvalues(evalf(eval(HeffR, x= a)))

(where a is some explicit numeric constant) than you'd get from decimal approximation of the roots of the polynomial.

@Adam Ledger Ah, but there is a field of math called "catasthrope theory". I even took a one-credit course in it once. That was a very long time ago (40 years), and I don't remember much. Anyway, see the Wikipedia article "Catastrophe theory".

@Fabio92 Fabio, you're missing a colon in the assignment to pw.

@maple2015 Good point about the first-order/second-order. For numeric solution, dsolve converts all ODEs to first-order systems (in the usual most-trivial way).

Did you try the stepsize option? And you still got a too-accurate solution? The classical methods are not supposed to use "controller steps".

I need to go to sleep now. 5:14 AM here. I'll look at it more when I wake. I'll also explain how to dig through the code.

@inteli I found the problem. It wasn't your fault. In the original lines, the Arrays need to be converted to Matrices. So, add Matrix to all the Import lines:

M1A:= Matrix(Import(...));

etc.

I don't know why Tom didn't have the same problem.

@maple2015 By default, dsolve is using h=0.005 (according to the help page). That's much smaller than your h, which is why there's no visible error. You can control it by adding the option stepsize= h to the dsolve command.

In principle, yes, you can dig through the dsolve code and find the algorithm, but it's nasty work in the case of dsolve. The formula used for adambash is given on the help page as

Y[n+1] = Y[n]+(1/24)*h*(55*f(t[n], Y[n])-59*f(t[n-1], Y[n-1])+37*f(t[n-2], Y[n-2])-9*f(t[n-3], Y[n-3])).

Perhaps that's all that you meant by "the correct algorithm which is used by Maple".

@Preben Alsholm Thanks, I wasn't aware of that; I've always added square brackets. But it makes sense; many kernel commands have similar behavior---the ability the treat non-explicit sequences as single entities.