Regardless of whether you see sys_ode:= in the output, it's clear that the assignment to sys_ode worked because your subsequent dsolve commands give the correct results. To plot them, do

sol:= dsolve([sys_ode, ics]);
plot(eval([l1, l2](x), sol), x= 0..2);

You may replace my 0..2 with any desired range.

I always do it this way because exactly the same code will work whether you're simply testing or loading from a library:

MyModule:= module()
local
    ModuleLoad:= proc() ... end proc,
    ModuleUnload:= proc() ... end proc,
    ... other locals ...
;
export
    ... some exports perhaps ...
;
   #Code that's executed during testing:
   ModuleLoad();
   ... perhaps some other executable code, but usually not ...
end module:

Note that I define all procedures in their local or export declaration rather than in the executable code section. So, the ModuleLoad() is, strictly speaking, not the very first thing executed in the "testing" portion; the assignments in the declarations are first. So, I imagine that I could construct some elaborate situation where that causes a problem. But it hasn't happened to me yet. Anyway, that same elaborate situation would cause the same problem with dohashi's method also.

Now, to directly answer your two questions:

At the time that your procedure setup is executed, the procedures GAinit and GAversion haven't yet been defined. They're just names. So the commands GAinit() and GAversion() do nothing (other than putting parentheses after unassigned names). If you define the procedures directly in the declarations section of the module, as I show above, you wouldn't have this problem.

The purpose of the warning messages that you show is to alert you to the possibility that you've mistyped a name. If you recognize the name that you're being warned about, then you haven't. Unless you're a bad typist, the vast majority of those warnings are inconsequential. Just check the spelling of the name.

I fear that you don't have the module "spirit" yet. All of your assigned global names should either be module locals or exports. Encapsulation is one of the main purposes of modules.

Anything that you protect in the module you should unprotect in the ModuleUnload.

There are many issues going on here. I will simply give you a clean and robust solution to your overall problem without completely discussing all of the issues. It is possible to make it work the way that you're trying, but I don't like that way; it's not robust.

Unfortunately, Maple---in some of its input formats---allows you to define a function of x via the syntax

f(x):= some expression;

even though this syntax is ambiguous to Maple and may mean different things in other input formats. If you look closely at your worksheet version, you'll see that the input format of the second input line is different (perhaps due to an inadvertent menu selection or control-key press), and consequently the output of that line reflects the different interpretation of the input. (The algebraic difference made in the output is obvious even at a quick glance.)

The simplest unambiguous way to define a function of x is

f:= x-> some expression;

The operator D can be used to take the derivative of a function (rather than of an expression), and it returns the result as a function. The nth derivative of a function of a single variable is either (D@@n)(f) or D[1$n](f); it's up to you which to use. (Only the latter syntax can be used for functions of multiple variables.)

Putting it all together, your work can be done by:

Kx:= tau-> your 1st expression;
Ky:= (D@@2)(Kx);
Dx:= Ky(0);

That will work in all of Maple's input formats and is never ambiguous.

Often, there's a situation where "your 1st expression" requires some type of evaluation or simplification before being turned into a function. Or maybe it's not strictly required, but rather simply preferred. In those cases, you can use

Kx:= unapply(your 1st expression, tau);

for the first line.

I'd rather not confuse you at this point by elaborating upon the situations where unapply should be used. You'll encounter one soon (probably within mere hours or days), and then just ask here again.

You'll never be able to debug your own code if you suppress the display of all intermediate results by ending every line with a colon (:) rather than a semicolon (;).

Your first plot command is

plot(exact, trial, x= 0..1);

It should be

plot([rhs(exact), trial], x= 0..1, legend= ['exact', 'trial']);

The Answer by Fabio fixes this problem in essentially the same way, so I give it a Vote Up. I simply prefer to use a single plot command, when possible, to do the same thing.

I agree with everything that Acer said above. I just thought that I'd state it more concisely and also list most of the low-level commands that print things as side effects.

Ordinarily (*footnote 1), what you see displayed are only the return values (*footnote 2) of the top-level procedures that you call. (This is even true for procedures that produce plots.) If a procedure has an untrapped error, then it has no return value, so all you see is the error message.

On the other hand, the following commands display things as a side effect, so that that displaying happens regardless of where in the procedure the command is executed: print, lprint, printf, and userinfo (that list does NOT include sprintf or nprintf). And many (most? all?) file output commands allow you to specify terminal as the file, which'll ordinarily (*footnote 3) cause display to the screen.

(*1) "Ordinarily" can be changed by printlevel, trace, or other debugging commands.

(*2) Return values of type function can be trapped and have their display format changed by procedures named `print/...`. In several very common cases (such as PLOT, Matrix, and Typesetting:-mrow) this trapping and reformatting is handled by an internal procedure. If you're debugging and suspect that this is happening, look at the output with lprint.

(*3) This "ordinarily" can be changed by writeto, i.e., things intended for the screen can be sent to a file instead.

Summarizing what happens in TSprintf: My procedure returns an object of type function whose function name is Typesetting:-mrow. That function name is trapped and the object is reformatted by the Standard GUI using internal code. So, my procedure actually returns a data structure rather than displaying something by side effect. Since the display is not done by side effect, it can be blocked by error.

Like this:

Sols3:= (H::algebraic, F::list(algebraic), i::posint, j::posint)->
   nops(
      select(
         s-> andmap(hastype, remove(evalb, s), hname),
         remove(
            s-> true in map(e-> (is(rhs(e) <= 0) assuming positive), s),
            [GTS(H, F, i, j)]
         )
      )
   )
:
(n,m):= (4,4); #Change to whatever size you want
Statistics:-HeatMap(Matrix((n,m), curry(Sols3, H, F)));

I do not know the formula for the polynomial. I guess that it depends on the function that's being interpolated? So, in the code below, you just need to fill that formula in where I put randpoly in the first line.

L:= (k::nonnegint, x::name)-> randpoly(x, degree= k):

make_pw:= proc(n::posint, interval::range(algebraic), x::name)
local 
   a:= op(1, interval), 
   h:= (op(2, interval) - a)/n, 
   k,
   x_k:= proc(k) option remember; a+k*h end proc
;
   unapply(piecewise(seq([x < x_k(k), L(k,x)/x_k(k)][], k= 1..n)), x)
end proc:

#applying it to your example:
f:= make_pw(10, 0..1, x);

#or, the same thing with decimal coefficients:
f:= make_pw(10, 0. .. 1., x);

The fs constructed above are procedures which when expanded, as in f(x), will be algebraic piecewise expressions if x is symbolic or just numbers if x is numeric.

Like this:

restart:
betas:= [2, 2.5, 5]:
colors:= table(betas =~ [black, red, blue]):
Eq1:= diff(y(x),x$2) + 'beta'*y(x) = 0, y(1) = sin(1), D(y)(1) = cos(1):
Eq2:= y = 'beta'*exp(x) + sin(2*x) + x^2:
dsol:= dsolve({Eq1}, numeric, parameters= ['beta']):
for beta in betas do
   dsol(parameters= [beta]);
   DP[beta]:= plots:-display(
      [plots:-odeplot(dsol, [x,y(x)], x= 0..0.1, legend= ['beta'(An)=beta]),
       plot(rhs(Eq2), x= 0..0.1, linestyle= dashdot, legend= ['beta'(Num)=beta])
      ],
      color= colors[beta]
   )
od:      
plots:-display(
   [entries(DP, nolist)],
   title= typeset("Variation of velocity for different ", 'beta')
);

As far as I know, the option implicit= true has nothing to do with the numeric use of dsolve; it only applies to symbolic solutions. What was your reason for using it? I wouldn't be surprised at all if some change made to dsolve's input processor between the two versions of Maple inadvertently caused it object to this input. Try removing it and see what happens. I can't test because you didn't provide your input or worksheet.

The symbol args has special meaning when it's used inside a procedure; it's essentially a reserved word. (Anything constructed with the arrow operator -> is a procedure, just as if it were constructed with proc() ... end proc.) So, you need to change args to something like Args.

Like this:

restart:
F:= (k::posint)-> assign(m||(1..2*k) =~ seq([dx||i, dy||i][], i= 1..k)):
F(3), m||(1..6);
                  dx1, dy1, dx2, dy2, dx3, dy3

A variable is only implicitly made local to a Maple procedure if an explicit assignment (using :=) is made to that variable within the procedure.

There are three (and only three) Maple commands that will accept a bound variable in their arguments and give it a kind of local status: seq, add, and mul. These are all built-in, not written in Maple. There's no way for someone writing a Maple procedure to give bound variables that will appear in their procedure's arguments that same status. This would be a great addition to the Maple language. Then the bound variables in numerous commands such as plot, int, diff, limit, etc. would be easier to use. As it stands, it's up to the procedure's user to make sure that bound variables are unassigned. This is a serious shortcoming of the whole Maple programming language.

Even the bound variables that are used with seq, add, and mul are not 100% local: If those variables are protected, it will cause an error. This is also a serious shortcoming, and one for which I see no excuse.

So, the answer to your final question is unfortunately Yes: If you're going to use a bound variable in a procedure and you want to be a careful programmer, then you need to declare that variable local, even if it's the bound variable for seq, add, or mul. An alternative that is practical and safe in the vast, vast majority of cases (but not 100% perfectly safe) is to begin the variable's name with an underscore.

The first method is overwhelmingly more efficient even if you don't have foreknowledge of nFrames. In Maple, there's no such thing as dynamically growing a list or set. If any change whatsoever is made to a list or set, then the entire list or set is reconstructed from scratch regardless of how large it is. But you can dynamically grow a table or Array.

Furthermore, there's no need to preallocate memory, although it doesn't hurt either. However, creating a list of zeros to initialize an Array in a complete waste. Arrays are essentially initialized to 0 anyway.

The issues in the first paragraph above are extremely important. Attempting to dynamically grow lists or sets may be the number-one source of inefficiency in Maple programs. The issues in the second paragraph are minor.

If you understand the notation of asymptotic time complexity: The first method is O(nFrames); the second method is O(nFrames^2). This is easy to demonstrate experimentally and easy to explain theoretically.

This issue has nothing to do with animation in particular. It is pervasive throughout Maple.

Upto my understanding of this subject, which is admittedly weak, the likelihood function is only properly defined for distributions with at least one symbolic parameter. That seems to be confirmed by both the Wikipedia article "Likelihood function" and the fact that your workaround using symbolic m worked. Given this, it makes sense that the result is always 1 when there are no parameters. In other words, What is the likelihood, or probability, that you've correctly estimated the parameters when there are no parameters? Of course it's 1.

What I'm wondering is What happened to the factors of 1/sqrt(2*Pi) that usually appear in the Normal PDF?

There's only one practical way to limit the time that a Maple command uses: Wrap the command in the appropriately named timelimit command. See ?timelimit. Using kernelopts(cpulimit= ...) for this is brutal, crude, and leads to lost work.

Further finesse is achieved by wrapping the timelimit command in a try-catch block. See the examples on the referenced help page.