Do you mean you want to see the mathematical difference between an ordinary integral and a contour integral?

is an ordinary integral.  Here the variable x runs over the interval [1,2] on the real line.  It can be thought of as the limit of the sum of pieces when the interval is split up into small subintervals, where

for the subinterval from x_j-1 to x_j.

On the other hand,

where C is a path in the complex plane, is a contour integral.  It can also be thought of as the limit of the sum of small pieces where the path is split up into small sub-paths, and

for the piece of path from z_j-1 to z_j.

Both ordinary and contour integrals can sometimes be computed by the Fundamental Theorem of Calculus.  Thus if f(x) has an antiderivative F(x) on the interval [1,2],

Similarly, if f(z) has an antiderivative on a domain containing the path C, and C starts at a and ends at b,

However, contour integrals, particularly over closed contours, can often be evaluated more easily by other means, in particular the Residue Theorem.

Maple's "method=contour" is something a bit different: it tries to evaluate an improper integral (say from to ) by relating the integral to (a limit of) contour integrals over closed contours and then using the Residue Theorem.  For example,



could be done in this way.

I'm afraid I don't understand you. 
Sum(Sum(x[i]*x[j], i=1..n),j=1..n) is the one that factors as Sum(x[i],i=1..n)*Sum(x[j],j=1..n). 
The sum for j <> i does not factor. 

Unfortunately, Maple does not seem to have very good tools for this kind of elementary symbolic manipulation of sums. 

I'm afraid it's difficult to give a detailed answer to such a question.  Option remember is certainly useful in some circumstances, but only if the same function is going to be called many times with exactly the same inputs.  That may or may not be true in your problem.  The simplify function does many different things, and you may get a speedup if you try something more specific (e.g. perhaps what you want is normal).

As for parallel processing, you might look at the help pages ?multithreaded, ?Grid and ?Threads.

The link to HW#7.mw does not work. Your other two files seem to be mixtures of fragments of Maple worsheet with other stuff, including what looks like Java code and Adobe Photoshop.
I think it may be difficult to extract the Maple parts. 

Note that is Pi, the imaginary unit is I, and the exponential function is exp.

> for n from -20 to 20 do
      x[n]:= exp(I*Pi/6 * n)
   end do:

> plots[complexplot]([seq(x[n],n=-20..20)], style=point);

 You might try looking at the help page ?Statistics,Fit. 

Perhaps if you told us your actual expression we might be able to give more specific and helpful responses.

Your f3 looks like it has one variable x

but appearances are deceiving.  There are actually two.

> lprint(indets(f3,name));

{x, `#msup(mi("x"),mo("&period;"))`}

I suspect that second construction was produced using the palettes.  Anyway, if you make it into an actual x, there's no problem.

> subs(%[2]=x, f3);

> plot(%,x);

You could try turning your equations into expressions and then using RootFinding[Isolate].

> eqs:= map(lhs-rhs, [f,g,h,i,j,k]);
   RootFinding[Isolate](eqs,[a,b,c,d,e,z]);

However, this seems to go on for a long time and use up a lot of memory.  This may be a very challenging problem for RootFinding[Isolate].

You might get other solutions by choosing a starting point in fsolve.  For example:

 > fsolve(eqs, {a = 100, b = 100, c = -100, d = -100, e = 100, z = -100});
   

  {a = 36.87647167, b = 22.65755089, c = 241.4881052,
       d = -18040.36902, e = 993.2673601, z = 4015.770590}

Do you mean you want to unite them visually (i.e. erase the boundaries between them)?  That's probably simpler than actually uniting the polygons, especially since the joined polygon might not be simply connected.  All you have to do is plot the polygons using style=patchnogrid.
Now perhaps you want to put back in the boundaries between different colours.

For example:

Data:= [[[[0,4],[1,3.2],[2,4]],[[1,3.2],[2,4],[2,2]]],
        [[[0,4],[1,3.2],[0,2]],[[0,2],[1,3.2],[2,2],[1,1.4]],[[0,2],[1,1.4],[0,0]]],
        [[[0,0],[1,1.4],[2,2],[2,0]]]];
Colours:= [red,green,yellow];
# original plot:
display(map(op,zip((d,c) -> map(polygonplot,d,colour=c), Data, Colours)),axes=none);

getedges:= L -> (seq({L[i],L[i+1]},i=1..nops(L)-1),{L[1],L[-1]});
Cedges:= [seq([seq](getedges(P),P=d),d=Data)];
outedges:= `union`(seq(convert(map(convert,select(t -> numboccur(t,C)=1, C),list),set),C=Cedges));
display(plot(outedges,colour=black),
 map(op,zip((d,c) -> map(polygonplot,d,colour=c), Data, Colours)),
style=patchnogrid,axes=none);

> convert(1.333333, rational, 7);

It's hard to know what caused this; probably not a virus.  But somehow, after some preliminary formatting information, your file seems to be completely corrupted.  I don't see any way of recovering it.

There are basically two ways to deal with a definite integral in Maple: symbolic and numeric.  For a symbolic integral, you want an exact formula for the result.  This will be calculated, if possible, by int, but the result might be extremely complicated.  Usually an endpoint of 1000 wouldn't make much difference, if any.  For a numeric integral, you want a decimal approximation to the result.  This can be done by evalf(Int(...)), avoiding any attempt at a symbolic solution.  Usually this is quite fast, although there may be problems e.g. if your integrand oscillates a lot. 

We might be able to give better advice if you gave us a specific example of the type of integral that's giving you trouble.

Images in JPEG, TIFF or BMP format can be imported into Maple using Read in the ImageTools package.  I don't know what graphics formats Matlab can produce, but if necessary there are ways to convert from one to another.  Maple can also produce graphics files in such formats.
The images can then be combined and viewed or written to a new image using ImageTools commands.  Getting the scaling right so the images can be compared properly might not be easy, though.

The root= option does make a difference, but (due to a bug) only the first time you draw the tree.  I have submitted an SCR.  Thus:

> G:= Graph({{1,2},{1,4},{2,3},{2,5}});
   DrawGraph(G, style=tree, root=1);

> DrawGraph(G, style=tree, root=2);
(same picture)

To draw the graph with 2 as the root, you can redefine the graph.

> G:= Graph({{1,2},{1,4},{2,3},{2,5}});
   DrawGraph(G, style=tree, root=2);

If you want a graph with different nodes having the same label, you can do something like this:

> G:= Graph({{a,b1},{a,b2},{b1,c1},{b1,c2},{b1,c3}});
   DrawGraph(subs(b1=b,b2=b,c1=c,c2=c,c3=c,G),style=tree,root=a);

Most mathematics manuscripts (for books or articles) these days are written in Latex.  Your prospective publisher may have specific style and formatting guidelines, and these are often available online from the publisher's web site.  You can use "Export As...", "Latex" from the File menu to make a first draft, but you will probably have to tweak the formatting somewhat.