I admire your curiosity, but you're asking the wrong questions. When a Maple program crashes merely because of the size of the input, it's usually for a very mundane reason: You've run out of memory. In the case of 10^(10^9)+2, it's computing the number itself that causes the crash before isprime is even called. You can verify that by simply entering 10^(10^9)+2 at a command prompt. So your experiment doesn't reveal anything interesting about isprime.

It's possible to trap errors with the try command. See ?try. Of course, if Maple just crashes, that's not going to help. But that's what's going to happen when you push the memory limits.

You can write the current value to a file many different ways  in Maple. The attached worksheet shows one way at the end.

Now, since you seem curious about these things, I present a much better way to test isprime and much more interesting questions to ask about it. It's all in the worksheet below.

Download isprime_complexity.mw

Now, if you want to continue this line of research, here's what to do:

1. By using Maple's help system and by asking Questions here if necessary, figure what the above program does. Write a brief paragraph explaining it.

2. By doing some research on the Internet, figure out why what the above program does is interesting, and write a brief paragraph about it. I'd start by looking up "time complexity" and "primality test" in Wikepedia.

3. Answer the questions that I pose at the end of the worksheet.

4. Come up with some similar questions to ask, and answer them.

If you're unsure how to modify the program to address any of the questions, feel free to ask.

You don't show the erroneous command in the worksheet. Thus I am guessing that it is

coeffs(%, [u[t], u[x], u[x, t], u[x, x]]);

In the future, please explicitly show the error message and the command that generates it.

The problem with the above is that the expression contains g(u[x]). Since it also contains g[u[x]], I'm guessing that you intended the former to be the latter.

Change the command solve(sys) to solve(sys, explicit). Then the results will be expressed as square-root expressions rather than RootOf.

The easiest change that you can make to correct the code is to change vector to Vector (uppercase V). The vector, with a lowercase v, is from a much older version of Maple. There's no reason to use the old form.

Yes, it's very easy. Wherever 10 appears in the format string, replace it with an asterisk *. Then in the sequence of values that fill formats, use decimals, value1, decimals, value2. This is IMO more robust than Acer's method and also consistent with standard C-language usage.  However, it does produce more-cryptic code. 

The observed phenomenon has nothing to do with tilde or map. The difference is between `convert/string`(...) and convert(..., string) when those are applied an object of type symbol that contains nonstandard characters and is thus enclosed in backquotes. The conversion from symbol to string is a primitive, kernel operation when done as convert(..., string); it doesn't involve a call to the Maple-level procedure `convert/string`. When that procedure is called, the extra quotes are used. 

The proper use of map is map(convert, L, string). The proper use of tilde is convert~(L, string). They produce identical results. Clearly, the tilde form is more compact and produces easier-to-read code.

It's not ~y; the relevant strings are *~ and /~. These are elementwise operators. See ?elementwise. For example, suppose the A and B are sets or lists of the same size or rtables of the same size and shape. Then A *~ B is equivalent to zip(`*`, A, B), i.e., it produces a set, list, or rtable whose entries are the products of the corresponding elements of A and B.

Set interface(prettyprint= 2, labelling= true) and it'll work.

Here's an overload of eval that makes it smarter. My intention is that it's smart enough to convert any bound variable used inside a procedure to a local.

restart:
local eval;
Warning....
eval:= proc(e::uneval, V::{posint, name= anything, {list,set}(name= anything)})
local r, v;
     if nargs=1 then :-eval(e)
     elif V::'posint' then :-eval(e,V)
     else
          v:= {`if`(V::`=`, V, V[])};
          r:= :-eval(
               evalindets(
                    e,
                    function,
                    f-> subs(map(x-> lhs(x)= convert(lhs(x), `local`), v), :-eval(op(0,f)))(op(f))
               ),
               v
          );         
          if procname::'indexed' and op(procname) = 'recurse' then
              r:= `if`(:-eval(r = e), :-eval(r), eval['recurse'](:-eval(r),v))
          else r:= :-eval(r)
          end if;
          `if`(op(0,r) = :-eval, 'eval'(op(r)), r)   
     end if
end proc:         

Now, your examples:

g:= a-> int(x+a, x= a..2*a):
:-eval(g(x)=g(z), [x,z]=~ 1);  #without Carl's correction
     3 = 5/2
eval(g(x)=g(z), [x,z]=~ 1);  #with Carl's correction
     5/2 = 5/2
(:-eval = eval)(g(x), x= 2*x);
     12*x^2 = 10*x^2

g:= a-> int(sin(sin(x+a)), x= a..2*a):
evalf(:-eval(g(x)=g(z), [x,z]=~ 1));  #without Carl's correction   
     .105207050696364 = .529440545264378
evalf(eval(g(x)=g(z), [x,z]=~ 1));  #with Carl's correction
     .529440545264378 = .529440545264378

And here are some examples for Edgardo to consider:

g:= a-> sum(f(x+a), x= a..2*a):
:-eval(g(x)=g(z), [x,z]=~ 1);  #without Carl's correction
     f(2)+f(4) = f(2)+f(3)
eval(g(x)=g(z), [x,z]=~ 1);  #with Carl's correction
     f(2)+f(3) = f(2)+f(3)

Physics:-Setup(redefinesum= true):
:-eval(g(x)=g(z), [x,z]=~ 1);  #without Carl's correction
     sum(f(2*x), x = x .. 2*x) = f(2)+f(3)
eval(g(x)=g(z), [x,z]=~ 1);  #with Carl's correction
     f(2)+f(3) = f(2)+f(3)

[Edit 1: Code corrected and example added due to VV's comment.]
[Edit 2: Code updated to work with eval's recurse option and to return unevaluated when appropriate.]

What you're calling a chimera is technically known to logicians and computer scientists as a "bound variable". The command depends and the types dependent and freeof are used to detect them or their absence. However, those commands are irrelevant to your dsolve question because there's an easy way to deal with that: option known. Here's an example:

alpha:= proc(x)
local t;
     if not x::numeric then return 'procname'(args) end if;
     evalf(Int(sin(t^3)*cos(t^2), t= 0..x))
end proc:

Sol:= dsolve({diff(y(x), x) = alpha(x)*y(x), y(0)=1}, numeric, known= [alpha]);

Note that the procedure alpha must contain the line that makes it return unevaluated when it gets non-numeric input.

Please don't post Questions as Posts. I already moved this one.

The letter e isn't a predefined value in Maple. To get e^5, you need to use exp(5).

The problem is that (unfortunately) Heaviside(a::algebraic) evaluates to something other than itself: It evaluates to Heaviside(a)! My preference would be that it return an error message. Perhaps this should be considered a bug of Heaviside. We can quickly look through the code showstat(Heaviside) and see where things go wrong. The argument a::algebraic passes through the type check in the proc line because an expression of the form a::b is of type algebraic! (I think that this should be considered the real bug.) Then between lines 23 and 24, the argument passes the type check linear(a). (This should also be considered a bug.) Then in line 30, the return value is set to Heaviside(a). Many other standard procedures, such as sin, return unevaluated when passed a::b.

All of the bugs mentioned above would be fixed if type(a::b, algebraic) returned false. According to ?type,algebraic, it should return false because `::` is not one of the 13 types listed, and a::b typechecks as false against all 13.

Now, turning to your patmatch command: patmatch(Heaviside(x), Heaviside(a)) returns false because the arguments aren't identical. There's no real pattern in the second argument because there's no ::. A perfect identity match is expected for any parts of the pattern for which there's no ::. This also explains why it returns true when you change a to x.

The difference between patmatch and typematch is that patmatch accepts as its second argument patterns which are far more complex than those allowed by typematch. The latter basically only allows type expressions prepended with name::. Examples:

patmatch(x+2, a::name + n::posint) returns true.
typematch(x+2, a::name + n::posint) returns an error message because name+posint isn't a valid type.
typematch(Heaviside(x), Heaviside(x)) returns an error message because x isn't a valid type.

I find Christian's explanation of the difference quite confusing and misleading, although it's technically correct, I guess.

If you use lprint on the results, you'll see that they are essentially the same. A 1-D Array whose indices start at 1 prettyprints as if it were a Vector, and 2-D Array both of whose indices start at 1 prettyprints as if it were a Matrix. Using lprint reveals the true nature of things.

Basically, prettyprinting allows almost anything to be displayed as if it were something else without changing the underlying value. If I wanted sin(1) to display as 42, I could write a one-line procedure to do that. Of course, prettyprinting is only useful when it shows some useful mathematical representation of the underlying object. Since a 1-D Array with indices starting at 1 is essentially a Vector, that's appropriate here.

Your code above the fsolve does not define, or even use at all, any variables named Eq1 or Eq2, yet you refer to them in the fsolve command.

See ?Statistics,Lowess. One of the examples shows doing an integration.