In Maple, square brackets cannot be used instead of parentheses for algebraic groupings. Thus, you need to edit the objective function. Unfortunately, since square brackets do have several other legitimate meanings in Maple, your error was not caught at the time that you entered p.

(This paragraph applies if you want the curve to go exactly through the given points (which is somewhat implied by the word interpolation).) The situation that you present is an extremely well-known drawback of polynomial interpolation. The usual alternative is to use a spline. This is a piecewise curve of low-degree polynomials, usually cubic, and usually made so that the resulting curve is differentiable at the split points (called knots). The drawback of a spline is that unlike a polynomial, it is not infinitely differentiable. So, use Maple command CurveFitting:-Spline.

(This paragraph applies if you only have a finite set of points.) If you just want a curve that gets as close as possible to the points but doesn't necessarily go through them exactly, then many more options are available, but you need to first decide on a template or parameterized formula for the curve, and then start with Statistics:-Fit. For example, you can find the best cubic polynomial that approximates the data. Or if you know that you want an increasing function without inflection points, the model may be y = C*x^P where C and P are parameters to be determined (Statistics:-PowerFit handles this specific case).

(This paragraph applies if you have an essentially infinite number of points; that is, you have some means (perhaps very complicated means) of numerically computing the function values to arbitrary accuracy over some interval.) So, you want some nice, relatively simple, algebraic function that approximates your not-so-nice numeric procedure over some closed and bounded interval. Solutions of this sort are in the numapprox package.

I can confirm that the situation is as you described. I think that this is bug, because the underscore-prefix convention is supposed to apply to automatically generated global symbols, not global symbols specified by the user. Here is a workaround:

OdeTest:= proc(Sol,ODE)
local 
   Names:= 
      [(indets(Sol, And(name, Not(constant))) 
         minus indets(ODE, And(name, Not(constant)))
       )[]
      ],
   _Cn:= [_C||(1..nops(Names))]
;
   subs(_Cn=~ Names, odetest(subs(Names=~ _Cn, Sol), ODE, args[3..]))
end proc:

Now just use OdeTest any place where you use odetest.

If you simply want it to pause indefinitely (rather than for a pre-specified length of time) so that you can do something else and then get back to it, then just use any command that expects user input, such as

readline(terminal);

If you trace the code that ensues from evaluating Ei(1, 1.), you'll see that the relevant code is in

showstat(`evalf/Ei/taylor`);

A simple alternating series approach is used. First, the value of Digits is increased slightly in line 2. The formula for the amount of increase is complicated (but only 1 line), but the end result is that if Digits starts with its default value, 10, then it's increased to 13. Second, there are some initializations in lines 3-6. Third, a very simple for loop in lines 14-17 accumulates the sum of an alternating series until reaching the first term that doesn't change the sum (at Digits=13). That's 15 terms in this case. Finally, the sum is added to Psi(1.) - ln(x), where x=1. but Psi(1.) is constant, independent of x.

The relevant alternating series can be obtained by

convert(Ei(1,x), FormalPowerSeries);

(That's equivalent to the series that Mariusz showed in his Answer above.)

And the code that I detailed above is equivalent to

S:= -Sum((-1)^k*x^k/(k*k!), k= 1..infinity) - gamma - ln(x);
evalf[13](eval(S, [x=1., Sum= add, infinity= 15])):
evalf[10](%);

except that the terms of the series are generated iteratively, so that no actual powering or factorial computations are done, and no foreknowledge of the number of terms is needed.

In the declarations section of foo, include the line:

uses Shorter_name= B;

Then call boo as Shorter_name:-boo.

Never use with inside a procedure or module. Use uses instead.

If you want to actually remove the assumptions on alpha, do

alpha:= 'alpha';

If you simply want alpha to be displayed as alpha rather than alpha~ (without actually removing the assumptions), do

interface(showassumed= 0):

Put the appropriate legend option in each individual odeplot. Then display will merge the legends correctly, even if there's more than one legend in each individual plot. So,

p1:= odeplot(lp1, ..., legend= ["step"]);
...
p2:= odeplot(lp2, ..., legend= ["impulse"]);
display([p1, p2]);

For the code Test that you show, the call must be Test(f) and not Test(f(x)). If you use Text(f(x)), you'll get weird results, but not an error message. It's worthwhile to force an error message like this:

Test:= proc(f::procedure) f(1) + f(2) end proc:

Now the call Test(f(x)) will give you an error message. The key is the ::procedure. The procedure is what Maple calls a type, and f::procedure will force f to be that type.^[1] There's no practical limit on how complicated or intricate a type specification can be.

It's easier to pass a procedure f than an algebraic expression such as f(x). But if you have a compelling need to pass f(x) instead, let me know; it's not that complicated. The complexity is that the procedure Test will either need to be told or need to figure out for itself what the variable x in the expression is. It would be a very bad practice (although Maple would allow it) to code Test to just assume that the variable is global x.

[1] Both f and Test are considered by Maple to be of type procedure. In ordinary mathematical English, we may refer to f as a function. That is fine, but f is not of type function in the way that that word would be used in actual Maple code.

You're confusing QR decomposition, a matrix factorization algorithm, with the QR (eigenvector) algorithm, which may use QR decomposition as an iterative step (but in practice usually doesn't). See the Wikipedia article "QR algorithm". If, for educational purposes, you want to implement the QR eigenvector algorithm in a way that actually uses QR decomposition, the steps for doing that are given in that Wikipedia article. But, note that that is not now considered a practical algorithm.

Please don't direct any followup questions at me if they go on and on with ridiculously verbose and ultimately meaningless code, as is your long-established style.

That is bizarre. I've never seen that __SELECTION, nor is it happening for me when I execute your code.

Here's a way around that. And, anyway, this is something you should do even if you don't get that weird output. Your function can be integrated once, for symbolic x, to obtain an algebraic expression in x, which can then be evaluated for any numeric x. Okay, that probably sounds complicated, but it's all done with one command: unapply.

g:= unapply(int(exp(-2*t^2), t= x-1..x) - int(exp(-2*t^2), t= x..x+1), x);
evalf(g(1));

If you know that you're always going to want to do evalf with g, then you might as well roll the evalf into g's definition, as in

g:= evalf@unapply(int(exp(-2*t^2), t= x-1..x) - int(exp(-2*t^2), t= x..x+1), x);
g(1);

By the way, it's obvious that g(0) = 0, so I hope that your purpose for doing this is something deeper than finding a root of g.

The freezing that you're experiencing from numtheory:-divisors(X) is due simply to Maple's attempt to format and display the lengthy output. It's not due to any computational inability. There are two things that you can do to prevent this:

1. (strongly recommended) Go to menu Tools -> Options -> Precision -> "Limit expression length to" and put in a relatively low number like 100000. Apply globally.
2. (not so great, because it's easy to forget) If you anticipate lengthy output, end the command with a colon.

Note that if the computation is done and you're stuck in the formatting stage or outputing stage, you're totally out of luck! This is much, much worse than being stuck in the computation phase (where you can kill only the problematic kernel through an OS program like Task Manager). To kill the display phase, you need to kill the GUI, which terminates your entire Maple session---all open worksheets---and any unsaved work in those worksheets will be lost.

It's incomprehensible to me how Maplesoft could let such a basic and demoralizing problem go unfixed year after year.

It's straightforward. You translate your symbols to Maple's VectorCalculus notation, subtract the right side from the left side, and simplify. If you get 0, it's proven. Like this (I've used G for your weird scalar function symbol):

restart:
with(VectorCalculus):
v:= x,y,z:
F:= VectorField(<f(v), g(v), h(v)>, cartesian[v]):
alias(G=G(v)):
Curl(G*F) - (G*Curl(F) + Gradient(G, [v]) &x F);
simplify(%);

I think that the error message is clear enough. The syntax A:-B searches module A's exports for something named B. On the other hand, the B without a module prefix is just accessing a local from a parent in the same manner as would happen in most programming languages, because exports are also local.

There are two exceptions, however, under which A:-B searches through all of A's locals, not just its exports: (1) If A is the keyword thismodule, or (2) if kernelopts(opaquemodules) is set to false.

The easiest programmatic solution would be to have the numbers in a plain text file, two numbers per line separated by a comma, and use ImportMatrix (see ?ImportMatrix). Many formats are supported, and you don't really need the commas, nor does the file really need to be plaintext.

I'm not sure what you mean by "then forgotten". Do you mean that the numbers must be forgotten (or erased, or deleted), as if they posed some sort of security risk? Or do you just mean that you don't care what happens to the numbers after you've processed them?