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?

I was aware of the existence of Maple's goto because I've occasionally seen it (very rarely) in code that I've looked at with showstat. I'd advise you not to use it. It looks dangerous. Note that what you think of as the statement label, common_exit, is really just a name, and common_exit: is simply a statement. If you try to send something to a non-existent label, I wouldn't be surprised at all if the kernel crashed.

In my youth, I once crashed an entire Burroughs 7700 mainframe computer (supporting hundreds of simultaneous users) by using a goto to a nonexistent label in a compiled Algol program. I got chewed out big time by the management. Fortunately, this label misdirection was very difficult to accomplish because the compiler was very strict about it. For one thing, it required that labels be locally declared as labels.

I avoid long chains of if x=... elif x=... elif ... ... else ... fi because it bothers me that x needs to be re-evaluated at each level. Plus they look untidy to me. Rather, I use something that I call a dispatch table---a table whose entries are procedures and whose indices are the values of x, which need not be numbers. Example:

Dispatch:= table([
   10 = proc() print("x = 10"); ... end proc,
   12 = proc() print("x = 12"); ... end proc
]);
if assigned(Dispatch[x]) then
   val:= Dispatch[x]()
else
   print("Don't know what to do with x =", x);
   val:= undefined
fi;

Of course, I don't actually use print statements.

The easy way to make a neatly formatted table is to use a Matrix:

interface(rtablesize= 21): #Allow display of matrices up to size 21x21.
Matrix([seq([t, evalf(-sin(t)), -.5*sin(.5*t)], t = 1 .. 20)]);

That's all there is to it! Note that I changed your curly braces {} to square brackets []. Don't use curly braces in any situation where the order of the contents within the braces matters.

With a tiny bit more effort, you can add column headers:

Matrix([[`time`, `Wave A`, `Wave B`], seq([t, evalf(-sin(t)), -.5*sin(.5*t)], t = 1 .. 20)]);

(which explains why I made the rtablesize 21 instead of 20).

The above can also be done with a DataFrame (see ?DataFrame), but, in this case, I didn't think it worthwhile to go that route.

The vector field <x, y> is not the same thing as the scalar function x*y. What you need is a path integral, not a line integral:

VectorCalculus:-PathInt(x*y, [x,y]= Path(<4*t, 3*t>, t= 0..1));   
     20

Or you may prepend Student:- to that; the syntax is identical.