I would put it the other way: the use statement is a shortcut for the :- operator.  That is, use allows you to reference the module one time and thus access any of its exports.  It is easier than writing the full name (modulename:-exportname) but has hidden dangers.  For example, a module might have a lot of exports, some you don't want to locally bind.  A safer form is the equation:

use exportname = somemodule:-exportname in
     exportname(...); ... ;
end use

It is never correct to use the with command in a procedure.  See the help page for with on this.

Note that there is a typo in the input, a multiplication is missing between the last epsilon1 and the adjacent opening bracket. Fixing that didn't solve the inherent inequality that Acer pointed out.

Nice idea, David.  The @@ operator could be used here to good effect.  That is, rather than doing f(f(f(n))) you can write (f@@3)(n).  Doing so then makes it convenient to parameterize the number of function applications.  I'd normally want to make the deck size (N) a parameter, however, that doesn't work with the repeated function composition operator (@@).  One could use foldl, however, I went a different route and wrote a shuffle generator that returns a shuffle routine for a particular deck size.  It also takes an optional keyword parameter 'inshuffle' that does an in-shuffle rather than the default out-shuffle. The parameter only takes effect if N is even. Here's the code

makeshuffle := proc(N :: posint
                    , { inshuffle :: truefalse := false }
                    , $
                   ) :: procedure ;
local pre, post;
    if N::odd then
        pre  := -1;
        post := 0;
    elif inshuffle then
        pre  := 0;
        post := -1
    else
        pre  := -1;
        post := +1;
    end if;
    proc(p)
    local pnew;
        pnew := 2*p + pre;
        `if`(pnew <= N
             , pnew
             , pnew - N + post
            );
    end proc;
end proc:

Here's a procedure that generates the disjoint cycle representation of the permutation generated by a given shuffle:

shuffle2cyc := proc(N :: posint
                    , { inshuffle :: truefalse := false }
                    , $
                   )
local k;
    shuffle := makeshuffle(N, _options['inshuffle']);
    convert([seq(shuffle(k), k=1..N)], 'disjcyc');
end proc:

An example on a 16 card deck:

shuffle2cyc(16);
           [[2, 3, 5, 9], [4, 7, 13, 10], [6, 11], [8, 15, 14, 12]]

As described in Martin Gardner's "Mathematical Carnival", the order of a shuffle is such that

 2^(order) = 1 (mod 2*ceil(N/2)-1

We can use numtheory[order] to compute this:

OrderShuffle := proc(N::posint)
local m;
    m := 2*ceil(N/2)-1;
    if m=1 then return 1; end if;
    numtheory:-order(2, m);
end proc:

OrderShuffle(52);
                                       8
 

eq := x^4 = a^2*(x^2 - y^2):
plots:-implicitplot(subs(a=1,eq), x=-1..1, y=-1..1, gridrefine=1);

It works for me.

1. Open Format -> Styles, scrolled down to C 2D Input, selected it, clicked 'Modify' then modified as I'd like. Note that the leading `C' stands for `character'.

2. Repeat with C 2D Output

3. Open Format -> Manage Styles. Select the 'User Define Style Set' radio button.  Click the New Style Set button. Click 'Select All' then 'Ok'. A menu will open that allows you to save this file.  Doing this makes it the default style. After the save you are returned to the Manage Styles box. Click Ok.

4. Exit Maple.  Restart.  It should come up with your new defaults.

It works for me.

1. Open Format -> Styles, scrolled down to C 2D Input, selected it, clicked 'Modify' then modified as I'd like. Note that the leading `C' stands for `character'.

2. Repeat with C 2D Output

3. Open Format -> Manage Styles. Select the 'User Define Style Set' radio button.  Click the New Style Set button. Click 'Select All' then 'Ok'. A menu will open that allows you to save this file.  Doing this makes it the default style. After the save you are returned to the Manage Styles box. Click Ok.

4. Exit Maple.  Restart.  It should come up with your new defaults.

That's nice.  I didn't think of that formulation but it makes more sense.

That's nice.  I didn't think of that formulation but it makes more sense.

I assume because it is relatively new [okay, not that new, but], it is not a builtin command, and its operation takes a while to learn and effectively wield. Maybe the real reason is that nested binary operations aren't all that common?

I assume because it is relatively new [okay, not that new, but], it is not a builtin command, and its operation takes a while to learn and effectively wield. Maybe the real reason is that nested binary operations aren't all that common?

When faced with a Maple construction I don't immediately comprehend, I frequently find it useful to exchange an active procedure with a dummy procedure.  In this case, I'll use %op as replacement for op.  We then get

 a := [a1,a2,a3,a4];
                                        a := [a1, a2, a3, a4]

 b := map(%op,[1,3,4],a); 
              b := [%op(1, [a1, a2, a3, a4]), %op(3, [a1, a2, a3, a4]), %op(4, [a1, a2, a3, a4])]

Each element of the resulting list, b, consists of a call to %op.  That is, the first element is

  %op(1, [a1,a2,a,3,a4])

If %op were replaced with the active op, we expect that this evaluates to a1, the first operand of the list a.  Similarly for the other three elements of the output list.  There is a simple way to convert %op to op, pass it through the value procedure (see the help page for value).  That is
 

value(b);

                              [a1, a3, a4]

When faced with a Maple construction I don't immediately comprehend, I frequently find it useful to exchange an active procedure with a dummy procedure.  In this case, I'll use %op as replacement for op.  We then get

 a := [a1,a2,a3,a4];
                                        a := [a1, a2, a3, a4]

 b := map(%op,[1,3,4],a); 
              b := [%op(1, [a1, a2, a3, a4]), %op(3, [a1, a2, a3, a4]), %op(4, [a1, a2, a3, a4])]

Each element of the resulting list, b, consists of a call to %op.  That is, the first element is

  %op(1, [a1,a2,a,3,a4])

If %op were replaced with the active op, we expect that this evaluates to a1, the first operand of the list a.  Similarly for the other three elements of the output list.  There is a simple way to convert %op to op, pass it through the value procedure (see the help page for value).  That is
 

value(b);

                              [a1, a3, a4]

I don't know what you are implying.  If you don't load the tailevalf package it won't work, of course. That is,

restart
sin(Pi/3)!;
                       (1/2*3^(1/2))!
evalf(%);
                      .9505776694

With tailevalf loaded, the ! operator is not the factorial. 

I don't know what you are implying.  If you don't load the tailevalf package it won't work, of course. That is,

restart
sin(Pi/3)!;
                       (1/2*3^(1/2))!
evalf(%);
                      .9505776694

With tailevalf loaded, the ! operator is not the factorial. 

My reasoning was the following.  Given

  (log(x+1)/x = sum(A[k]/x^k, k=0..infinity)  as x -> infinity

The term on the left approaches 0, so A[0] = 0.  Multiply both sides by x.  Now the term on the left approaches infinity, the term on the right goes to A[1] (because A[0]=0).  This might not qualify for a proof, but it is suggestive.