I just posted an answer to this problem in my blog.

This site is really good, but if you don't get an answer within a couple of days, then it is unlikely that you will get an answer later.  So for this question, I would turn to technical support.

I have never seen an english translation, sorry.  But I have seen an online version of the French original!

Personally I rather like Goursat's Cours D'analyse (I have the 3 volumes, in the original French).  I have been meaning to find and purchase Cauchy's too.

The help pages used to be online (not hosted by Maplesoft though), but no longer.  I agree, that would be really useful.  It would give Maplesoft some nice publicity, so I don't know why it has not been done.

You define G in terms of 2 values (r and r') and then use it with 3 values in your boundary conditions.  Also, is r' known?

Of course your P1 can be had in closed-form:

 > assume(x>0,m>1);P1:=(x,m)->sqrt(x)/(sqrt((x+m)^2-1)*(x+m+sqrt((x+m)^2-1))):

which promptly returns 2/3*2^(1/2). P3 seems to be a much harder nut to crack, either in closed form or even asymptotically.

There is no Classic on the Mac.

Maple doesn't really like complicated boundaries, but you can do

f1 := x -> sum(1/n^2,n=ceil(x)..infinity);

Another way to do this is to transform the function instead of the bound:

f2 := x -> sum(piecewise(n>x,1/n^2,0),n=0..infinity);

Both of these plot fine, although the second one is rather slow. That is because it is all done numerically, while the first one has a closed-form, namely

Psi(1,ceil(x))

Maple does this integration using FTOC, and gets the indefinite integral wrong, ie already int(diff(A(B(q,r)),q),r) = 0.  The bug appears to be (below) IntegrationTools:-Indefinite:-Homotopy:-Integrate, which is a newer routine. Tracing from there it seems the problem is in an interaction between what `ODEtools/Solve` returns and what PDEtools:-dchange does with it (ie I think the bug is below dchange.

More precisely, the following seems wrong:

> PDEtools:-dchange(r=RootOf(t2-B(q,_Z)), diff(B(q,r),q), t2=B(q,r), [t2],known=all);

                                  0

If you try hard enough, you'll figure out that your field variable contains a module which exports many things, = included.  So when you rebind field's exports (which is what 'use field in' does, that rebinds = as well, which leads to the problems you encounter.

The fix should have been as simple as

    isSolving := is(eval(equationToUse, [x :-`=` field:-random(), y :-`=` =field:-random()]));

but that does not work - the parser objects. And eval doesn't like the list. So another rewrite:

    isSolving :=  eval(equationToUse,{:-`=`(x, field:-random()), :-`=`(y, field:-random())});

gets us closer. This issue here is even thornier -- you are trying to define an equation in a Galois Field without actually evaluating it, and then substituting things in. That can be done too, but requires some awful hackery:

use field in
    eq1 := '''x - y^2''':
    eq2 := '''x^2 - y^4''':
    equationToUse := eq1;
    isSolving :=  eval(equationToUse,{:-`=`(x, random()), :-`=`(y, random())});
end use;

You have to move the definition of the equations into the scope of use. But you also need that triple-uneval! I must admit that I am at a bit of a loss to explain why 3 unevals are needed. This is the first time I encounter a situation where more than 2 unevals are needed in my 23 years of using Maple.

Here is a (sub)routine you could use.  It accepts as input

1. a name (the variable for the polynomials)
2. a list of polynomials
3. a list of breakpoints

and outputs a function of one variable.

mkPiecewise := proc(x::symbol, pl::list(polynom(anything,x)), bl::list(numeric))
    if not (nops(pl) = nops(bl)) then 
        error "expects the same number of polynomials and breakpoints but got %1 polynomials and %2 breakpoints", nops(pl), nops(bl);
    end if;
    unapply(piecewise( op(zip( (pol,bp) -> (x<=bp, pol), pl, bl ))),x);
end proc;

There are several important pieces of Maple programming used here:

1. The argument-checking power (see how pl's type depends on x?)
2. zip - to act simultaneously on 2 lists
3. inline functions - what is used in the zip
4. expression sequences - what the inline function returns and what piecewise wants [thus the op call]
5. unapply - turning an expression into a function
6. lexical scoping - so I can access x directly within the nested function

I have introduced one novelty over standard Maple: a meaningful (to the user) and helpful error message.

This is known as "premature evaluation", and there is no good way to stop Maple from doing it, at least if you use ^.

You can, directly or indirectly, program your own power function that does not suffer from this problem.  The drawback of course is that this new function is unknown to the library, and thus you have to program a lot of things yourself.

Lists are normally non-mutable objects, and Arrays are mutable.  At some point in the past, some brain-dead person decided it might be a good idea to make lists mutable too by making an implicit copy for the user (since the underlying object remains non-mutable).  Well, some somewhat cleverer person noticed that this is astonishingly inefficient, and can silently kill the efficiency of user code that "seems" to otherwise work.  But instead of fixing this mistake, which might break some horrible code (but code which functions for small sizes), some manager decided the solution was to put a hard limit on the sizes of lists that would be silently ``conveniently'' copied, a compromise that made everyone groan but was at least acceptable to all camps.

Now, would you really expect this comedy of errors to be well-documented?

I have said it multiple times: one of the dangerous side-effects of total backwards compatibility is that design mistakes can't be fixed.  This means that new designs really ought to be clearly 'right' before they are released.  That would imply a very long Beta period where some features are pulled from the final product when design flaws are found.  By the way, I am aware that there is a flaw in my reasoning - it makes a (very reasonable to me) assumption that appears to be false.  Let's see who can find out what my false axiom is ;-)

How do you tell from just a number which of its digits are significant?  Doesn't that need an error analysis of the process by which you generated it?

You might want to look into evalr.

You should strive to learn just enough Maple on your own to enter your equations in Maple syntax -- you can use the palettes and the equation editor to make it easier, just remember to put an explicit space when you mean multiplication, or better yet, put in explicit multiplications.  Then you'll find that people here will be much more likely to take interest in your problem.