I tend to use convert/list because it shows intent, and thus is clearer, unless there is a significant performance reason for doing otherwise.  On that grounds, this technique is questionable, because for most uses the performance gain is negligible.  Still, eliminating the need for a counter has a certain appeal.

Yes.  In order of speed, with fastest first

 {indices(T,'builtin')}
 {seq(T[i], i=1..cnt)}
 map(op,{indices(T)})

The difference isn't huge, say 5% between each. 

The chief appeal of using the index rather than the entry to save the value is that the code is slightly smaller; no need for allocating and incrementing a counter.  By the way, your route-finding post inspired this, I noticed that you used T[val] := val (or something similar), with val as a dummy index, thought that a clever way to avoid a counter, then realized the entry could be eliminated (made NULL).

What form is the input?  That is, is it a string that needs to be parsed?  Note that Maple has prefix command for the arithmetic operators, so you could do

`/`(`*`(a,b),`+`(c,d));       
                                                                  a b
                                                                 -----
                                                                 c + d

As John points out, the algorithm used in ListTools:-SearchAll is worst-case O(n^2) when the list consists of all items that are being searched.  

Assume that a list of n elements has m matches, uniformly distributed.  It can be shown that the algorithm is then O(k1*n + k2*m/2*(n+1)), where k1 is the coefficient for member and k2 the coefficient for allocating memory/copying (which is what L[p0..-1] must do).  A simple linear search is O(k3*n). If we equate the estimates and solve for m we get

   m = 2*n*(k3-k1)/k2/(n+1) ~ 2*(k3-k1)/k2

The implication is that there is a magic number m, such that if there are more matches than that in a uniformly distributed list, then it is faster to use a simple sequential search. 

Here is a faster sequential searcher than Alec's proposal.

SearchAll2 := proc(n,L)
local i;
    seq(`if`(L[i]=n,i,NULL), i=1..nops(L));
end proc:

Testing on my machine indicates that, for equal time m ~ 50 while for equal memory usage m ~ 10.

A general vector space does not have an inner product. Without an inner product there is no method for determining whether two vectors are orthogonal, or computing their norm.  You have not specified an inner product for the given space.  Alec's response assumed a typical one for such a space, that is, given two real functions, f, g, the inner product is

  <f,g> = Int(f(t)*g(t), t=-infinity..infinity)

That isn't the only possible inner product on this vector space.

A general vector space does not have an inner product. Without an inner product there is no method for determining whether two vectors are orthogonal, or computing their norm.  You have not specified an inner product for the given space.  Alec's response assumed a typical one for such a space, that is, given two real functions, f, g, the inner product is

  <f,g> = Int(f(t)*g(t), t=-infinity..infinity)

That isn't the only possible inner product on this vector space.

This seems to work (convert is an ImageMagick command)

convert original.eps -bordercolor white -border 0x0 visible.png

Using a Matrix (which is a mutable structure, meaning, more or less, that you can change it without allocating more memory) is a good thing.  You might try using CodeTools[Profiling] to determine what part of your procedure is allocating memory.

Using a Matrix (which is a mutable structure, meaning, more or less, that you can change it without allocating more memory) is a good thing.  You might try using CodeTools[Profiling] to determine what part of your procedure is allocating memory.

Yes. I'll modify it.  Doing so is slightly tricky and might be instructive.  Part of the fun is doing this in a way that the resulting module can be saved to a library that is usable with either 32 or 64 bit Maple (that is, the byte-size is determined at run time and not load time).  I think I got right.  Note that if you read the file rather than loading it from a library you'll have to call the Compile export.   Normally one could call the load procedure just before the end of the module assignment, however, that doesn't work here because when saving module the procedures cannot be compiled.

Actually I see I didn't get it quite right.  The substitution in the final use statement at the end of the module assignment occurs when the module is assigned, so the type is set when the library is created.  I originally had this in the procedure that is called when the module is loaded (here Compile), however, I was trying to modify it so that it would work for those users not accustomed to creating and loading libraries.  Is there a nice way to handle that?  I suppose I could put code into Permute to force the reassignment (and compilation), if not done, but that seems ugly.

I submitted this.

Thanks, Alec, for the pointer.  I vaguely recalled that there was already a package for doing this, but could only think of combinat, which doesn't include an iterator for permutations.  I'll have to familarize myself with combstruct.

Thanks, Alec, for the pointer.  I vaguely recalled that there was already a package for doing this, but could only think of combinat, which doesn't include an iterator for permutations.  I'll have to familarize myself with combstruct.

I believe it was added in Maple11 (possibly 10), along with _params, _passed, _options, and the _nxxxx names corresponding to the number of each.  Some of these are equivalent to args and nargs.  The _options is especially handy for passing on keyword parameters.

Compared to the original, I find the use of explicit parameters to be clearer.  As a bonus, it removes the need for the explicit parameter checking, because that is handled automatically.

mymaptype := proc(typ::type, func, expr)
    if type(expr, typ) then map(func, expr, _rest);
    else func(expr, _rest);
    end if;
end proc: