I only looked at the worksheet above for about 10 seconds, so I might ask something in this Reply that you already answered. Anyway, it appeared that you're using a self-coded RK2. I have several questions about that:

1. What happens if you use dsolve(..., numeric, method= classical[rk2], stepsize= ...)?
2. What happens if you use self-coded RK3 or RK4?
3. What happens if you use rk3 or rk4 in question 1?
4. Do you think that the variable stepsizes used by the standard IVP methods (rkf45, etc.) are causing your problem? They can be limited.

@sursumCorda It's not hard at all---at least it's not hard in Maple---to make a few easy adjustments to the procedure that I already gave to do all of

• Turn it into a procedure that returns both the depth and the leaf count, without redundant calculation;
• Do that in a way that makes sorting by depth and then leaf count trivial;
  and
• Address your concern regarding rtables.

Thus:

DepthAndLeafCount:= E->
local e:= `if`(E::rtable, convert(E, list, 'nested'), E), r:= [op](e); 
    1 +~ `if`(e::atomic or r = [e], [0$2], ([max,add]@~curry~(op~, [1,2])@thisproc~)(r))
:

To sort a list of expressions E in the specified manner:

sort(E, 'key'= DepthAndLeafCount)

@MaPal93 So, now that Tom has elaborated regarding fsolve, I'll elaborate regarding undefined, because I realize that my previous comment may have been a bit cryptic. Like many things in numerical analysis, fsolve is  an iterative process attempting to create a numeric sequence (or a sequence of numeric vectors) that converges in some sense (I suppose that you have at least enough basic topology knowledge to know precisely what convergence means). Now, I've learned over the years that despite our best efforts (e.g., using all the tricks that Tom has provided), there will always be some cases where fsolve doesn't converge. Indeed, I don't think that I've ever had a practical system of nonlinear equations with parameters and more than 50 sets of parameter instantiations where I could get fsolve to give an answer for all instantiations. So, whenever you get a non-answer from fsolve, whatever values that would've gone into your plots had it returned numeric values should be replaced by the keyword undefined.

@vv Okay, that's a reasonable objection. So, without using atomic, or even string or indeed any type not used in the original, you can still defensively program it to protect against both

• any new types of basic data structures added to Maple in the future 
  and
• any infinite recursion errors of the present kind

via

LC := proc(expr)
local ope;
    if expr::{numeric,name} or (ope:= [op](expr)) = [expr] then 1
    else add(map(thisproc, ope)) + 1
    end if
end proc;

If that condition is rephrased (just for mathematical readability, not for Maple coding) as
   [op(expr)] <> [expr] implies expr::{numeric, name},
then I think that you can see that it's essentially close to atomic although not exactly the same as atomic, which by Maple's definition is map('f', expr) = 'f'(expr).

I am adding this (formally, without directly amending) to my Answer:

My Answer's title, "Not intended for strings", is not quite correct; perhaps it should be "Can't work for strings". Indeed, the programmer's intention (as much as can be discerned) was likely that it work for any input expression. However, due to the obvious bug (if you read the recursive procedure), it gets stuck in an infinite recursion if its input can't be ultimately decomposed into numbers and names by repeated application of op. In other words, the only "leaves" that it'll accept on the expression's "tree" are numbers and names. This would perhaps be reasonable if the intention were only to process algebraic expressions all of whose subexpressions are also algebraic.

@nm Also, see the help page ?SoftwareMetrics,HalsteadMetrics. It's not exactly the same thing as leaf count, but in some ways it's much more useful. Another useful one is codegen:-cost. It counts the various arithmetic operations separately, but it's trivial to add those separate counts.

@nm I suppose that you're right about Maple should provide. But it's trivial to write your own. I thought that you would after reading that code. Here's mine:

LeafCount:= e-> `if`(e::atomic, 1, 1+(add@thisproc~@[op])(e)):

Using this on your lengthy piecewise expression from an earlier Question today

LeafCount(ff);
              16814

which is the same value returned by MmaTranslator:-Mma:-LeafCount.

@vv You definitely should change {numeric, name, string} to atomic!

If I click in MaplePrimes on the "Active Conversations", then I get a list of the 50 most-recent threads, with the first few words of their titles. So, for this thread, that's "why Maple 2023 gives internal error..." You see, the only part that's shown has extremely low information content, and is likely to be an exact match for other titles. The error message alone is sufficient title.

I know that MaplePrimes advises you to phrase Question titles as questions. Whoever wrote that advice is wrong. They apparently have no idea on how technical and scientific information should be organized for long-term storage. They seem to be more concerned with style than substance.

@tomleslie Since the OP requires 10-digit precision due to the courseware app being used, it should be noted that only this will give it without adjusting Digits:

evalf(D[1$3, 2$4](f)(-1, 2)); #no decimals!
                          205.6236296

@nm There is a movement in Maple towards using strings rather than symbols as option values for new commands. However, it should be noted that is, coulditbe, and _EnvTry:= 'hard' all existed in Maple before strings were even introduced. Prior to that introduction, symbols (often enclosed with `...`) were used for all cases where strings would be used today.

@sursumCorda According to the definitions and test code in this blog post "Programming Research Laboratory: Lexical and Dynamic Scope" by Ming-Ho Yee, Maple uses dynamic scoping. Yee's test code is

x <- 1
f <- function(a) x + a
g <- function() {
  x <- 2
  f(0)
}
g() # what does this return?

Translated into Maple:

restart:
x:= 1:
f:= a-> x+a;
      f := a -> x + a 
#Note the x in the displayed procedure

g:= proc() :-x:= 2; f(0) end proc:
g();
                               2

Yee says output 1 means lexical, and 2 dynamic.

It makes no difference whether one uses proc or ->, or whether x is an environment variable or a regular global. If we make x into what Maple calls a lexical variable, the results are the same:

restart:
f:= proc(a) 
local x:= 1, f1:= a-> x+a, g:= proc(a) x:= 2; f1(a) end proc; 
    g(a)
end proc:
f(0);
                               2

This is all good, the way things should be. I couldn't imagine extensively programming with symbolic variables (i.e., variables that don't necessarily evaluate to something other than themselves) in a lexically scoped environment, especially in an interpreted (i.e., not compiled) language like Maple. It'd also make weird situations where a procedure could come from a different file (or library) than the code that uses the procedure.

If you want to force a global variable in a procedure to assume a certain value for all time, that can be done with subs:

restart:
x:= 1: f:= subs(_x= x, a-> _x+a);
      f := a -> 1 + a 
#Note the absence of _x in the displayed procedure

f(0);
                               1

This subs thing only works when _x is global. This is a very powerful technique for creating efficient procedures on-the-fly from procedure templates.

@MaPal93 No, it's not necessary to first create a sequence of plots and then loop through them sending each to a file. And, if you do first create the sequence, it's not necessary to put it in an array (with the angle brackets); putting it into a list (with square brackets) works just as well. If your actual plots use a lot of memory, it might be beneficial to avoid the sequence. 

@MaPal93 Without delving into the details of your particular case (which I don't feel like pursuing at the moment), I'll advise you thus: Any numeric value representing a plot coordinate can be replaced with the keyword 'undefined'. These will simply appear as nothing at all in the plot. Example:

restart:
f:= x-> piecewise(abs(x-3/2) < 1/2, 'undefined', x^2):
plot(f(x), x= 0..3);

@AHSAN Running your most-recent worksheet in Maple 2023 (with no changes!), I get the following plot. 

1. Is this plot different from what you get (presumably in Maple 2022)?
2. Is this plot (shown below) what you want to get?
3. If not, then precisely how do you want the colors changed?

The cutting off of the third digits (the right side) of the legends is a separate issue.

In my worksheet itself, the above plot displays with a very ugly font used for the tickmark labels (but not the legend labels). I don't know why that is corrected by my context-menu Copy-As-Image followed by Ctrl-V paste into MaplePrime. Anyway, that's also a separate issue from the colors.