I'm not sure what you want, maybe something like the following:

charpos := proc(S :: string)
local pos, char, T, eq;
    for pos to length(S) do
        char := S[pos];
        T[char][pos] := NULL;
    end do;
    table([seq(lhs(eq) = [indices(rhs(eq),'nolist')], eq in op(op(T)))]);
end proc:

S := StringTools:-Random(10^3, 'alpha'):
pos := charpos(S):
pos["j"];
[696, 565, 308, 160, 46, 187, 907, 661, 300, 348, 741, 194, 458, 375, 577, 505, 109, 705, 965, 482]

You could use the following to convert the table to a string.

postostr := proc(T::table)
local S, i, char;
    S := table();
    for char in [indices(eval(T),'nolist')] do
        for i in T[char] do
            S[i] := char;
        end do;
    end do;
    StringTools:-Join(convert(S,list),"");
end proc:

I'm not sure what you want, maybe something like the following:

charpos := proc(S :: string)
local pos, char, T, eq;
    for pos to length(S) do
        char := S[pos];
        T[char][pos] := NULL;
    end do;
    table([seq(lhs(eq) = [indices(rhs(eq),'nolist')], eq in op(op(T)))]);
end proc:

S := StringTools:-Random(10^3, 'alpha'):
pos := charpos(S):
pos["j"];
[696, 565, 308, 160, 46, 187, 907, 661, 300, 348, 741, 194, 458, 375, 577, 505, 109, 705, 965, 482]

You could use the following to convert the table to a string.

postostr := proc(T::table)
local S, i, char;
    S := table();
    for char in [indices(eval(T),'nolist')] do
        for i in T[char] do
            S[i] := char;
        end do;
    end do;
    StringTools:-Join(convert(S,list),"");
end proc:

As a follow-up [to jakubi's question, above], I lost some enthusiasm when I realized (obviously) that the generated graphs (trees) pretty much all look alike.  That is, they reflect Maple's type structure. As an example, the code would produce

(**) with(WhatType): 
(**) WhatTypes(3/4*x^2+x+1);
{+, algfun, polynom, radfun, ratpoly, scalar, algebraic, anything, appliable, expanded, quadratic, radalgfun}

(**) MinCover(%):           
(**) MakeTree(%):           
(**) PrintTree(%):    
    anything
        algebraic
            +
            radalgfun
                algfun
                    ratpoly
                        polynom
                            expanded
                            quadratic
                radfun
            scalar
        appliable

The usual way to do this is the following

getarrows := proc(x0, y0, xd, yd, T, x1, y1)
local DEsol, tm, j, wl;
global x,y,t;
    wl := interface('warnlevel'=0); # note that the original value is returned, saving one call.
    try
        DEsol:= dsolve({xd,yd,x(0)=x0,y(0)=y0}
                       , numeric
                       , 'events' = [[y(t)-y1,'halt'],[x(t)-x1,'halt'],[x(t),'halt']]
                       , 'output=procedurelist'
                      );
        tm:= floor(subs(DEsol(T),t));
    finally
        interface('warnlevel'=wl); # restore warnlevel even if an error occurs
    end try;
    seq(subs(DEsol(j), [x(t), y(t)]), j = 0 .. tm);
end proc:

For this particular case there is a simpler method that uses an undocumented environmental variable in dsolve (because it is undocumented, it won't necessarily be supported):

getarrows := proc(x0, y0, xd, yd, T, x1, y1)
local DEsol, tm,j, wl;
global x,y,t;
    _Env_in_maplet := true; # silence event warnings during integration
    DEsol:= dsolve({xd,yd,x(0)=x0,y(0)=y0}
                   , numeric
                   , 'events' = [[y(t)-y1,'halt'],[x(t)-x1,'halt'],[x(t),'halt']]
                   , 'output=procedurelist'
                  );
    tm:= floor(subs(DEsol(T),t));
    seq(subs(DEsol(j), [x(t), y(t)]), j = 0 .. tm);
end proc:

Environmental variables (see ?envvar) are restored after exiting from a procedure, so try/finally is not needed.

You recall correctly.  I haven't touched it in a while.  Did I ever post the hierarchy I made of all of Maple's numeric types?  I recall getting some minor feedback on it, so maybe I did. 

A fraction is a ?subtype of complex(extended_numeric):

subtype(fraction, complex(extended_numeric));
                                                        true

I'm wondering why you expect map(f, y * z + x) to return f(y) * f(z+x).

What do you expect map(f, x + y*z) to return? 

Note that the second argument to the two map functions are mathematically identical and will be rendered identically in the same Maple session.  That is, because of ?operator,precedence, y*z + x is equivalent to (y*z) + x, which is mathematically the same as x + (y*z). 

A better question, what do you expect map(f, x/y) to return?  How about map(f, 3*x/4)?  Understanding those---which requires some knowledge of how Maple represents expressions---should enhance your ability to use map[le].

You're welcome.  My plan is to improve it---tighten it up a bit, add some headers, etc---once a final location is chosen (assuming it is).  Your estimate on the frequency seems about right. 

Here is a partial example of what I am expecting could be posted there.

The add/sum confusion

Maple provides two procedures, ?add and ?sum, which at first glance appear to do the same thing, sum an expression over a range.  This similarity is a frequent cause of misunderstanding and subtle errors.  The procedures have different purposes and evaluate their arguments differently.  The add procedure is intended to sum explicit values.  The sum procedure is intended to compute a symbolic summation.  As an example of each

add(k, k=1..3);
                                       6

sum(k, k=1..n);
                                                                2
                                                         (n + 1)
                                                        -------- - n/2 - 1/2
                                                            2

If we call add with a symbolic range, it returns an error

add(k, k=1..n);
 Error, unable to execute add

Because sum is able to handle explicit values in a range, it is frequently used for this task even when add is the better choice.  Let's use sum in a way it is not intended, that is, to sum the elements of a list:

L := [a,b,c,d]:
sum(L[k], k=1..4);
                                a + b + c + d

That appears to work (we'll return to it shortly), so let's now use sum with a Vector.

V := <a,b,c,d>:
sum(V[k], k = 1..4);
Error, bad index into Vector

What went wrong? 

The problem is that sum, like most Maple procedures, evaluates its arguments before calling the procedure.  When the argument V[k] is evaluated, Maple raises an error because k evaluates to itself and the symbol k is not a valid index for a Vector.  So why, you might ask, does the example with the list work?  The reason is that Maple is happy to create the symbolically indexed expression L[k], which expands to [a,b,c,d][k].  Try it:

L[k];
          [a, b, c, d][k]

How can we avoid the error?  One approach is to prevent sum from evaluating its first argument.  More precisely, we want to delay the evaluation.  That can be achieved by using forward quotes around the argument:

sum('V[k]', k=1..4);
                               a + b + c + d

Using forward-quotes has its place, however, there is a better method, and that is to use add.  It avoids the error by using ?SpecialEvaluationRules. That is, its first argument is not evaluated before it is processed.  That prevents the "bad index" error from being raised.  Thus

add(V[k], k=1..4);
                              a + b + c + d

When add fails

Because add does not evaluate its first argument, it may give unexpected results if the index variable does not explicitly occur in the first argument. Consider the folowing anonymous procedure call

proc()
local k, y;
    y := 1/k;
    add(y, k = 1..3);
end proc();
                          3/k

That is not what is desired.  The reason this happens is somewhat subtle; maybe I'll expand on it later.  One way to solve the problem is the converse of what we did with sum, that is, instead of delaying the evaluation of the arguments, we delay the evalution of the procedure.

proc()
local k,y;
   y := 1/k;
   eval('add'(y, k=1..3));
end proc();
                           11/6

That works because, by delaying the evaluation of add (but not its arguments), we effectively prevent its special evaluation rules from being applied.  That is, its arguments are evaluated before being passed to add. The clever reader might ask how can we handle something like

proc()
local k,y,V;
     V := Vector([1,2,3]):
     y := 1/k:
     add(V[k]*y, k=1..3);
end proc();
               6/k

We cannot just delay the evaluation of add, that would raise the bad-index error.  Instead we need to delay both add and V[k].

proc()
local k,y,V;
     V := Vector([1,2,3]):
     y := 1/k:
    eval('add'('V[k]'*y, k=1..3));
end proc();    
                                       3

Yes, I had looked at that page before posting this.  I hadn't, however, read all the responses and now note that, not surprisingly, Doug Meade has mentioned the same example I just gave (sum vs add).  I'm not too concerned whether the actual location is hard for a user to find; my motivation is to make it easier for responders to quickly post a link to preexisting material. Of course, it should be easy for the responders to find the link...

Robert Israel's description of top ten errors is good, but I'd prefer each response be an actual page, and preferably not worksheets served up by MapleNet, which can be a little slow. I'm thinking there should be a new book entry, say, Frequent Answers, where we can create subentries for each each topic.

I find it curious that you are using the undocumented ?PIECEWISE rather then the standard ?piecewise to construct a piecewise expression.

Q^(-1) works, as does 1/Q.

Q^(-1) works, as does 1/Q.

Your mention of Markov chains reminded me that I had been meaning to look up the etymology of ergodic.  A web search turned up this, which is fascinating.

Your mention of Markov chains reminded me that I had been meaning to look up the etymology of ergodic.  A web search turned up this, which is fascinating.