andmap(A,a*b*c) should call A just once, since the first call returns false; andmap uses McCarthy shortcircuiting.

I'll retract the issue with ormap; I must have done something weird since it works now.

Looks like a bug in andmap. Consider

A := proc(s) option trace; type(s,'numeric') end proc:
andmap(A,2*a);
{--> enter A, args = 2
                                     true

<-- exit A (now at top level) = true}
                                     true

A is only called with the 2 operand. The same problem occurs with ormap:

ormap(A, a*b);
{--> enter A, args = b
                                     false

<-- exit A (now at top level) = false}
                                     false

The for-loop is not necessarily quadratic in memory, that depends on what foo returns for each term in the sum. If it returned a numeric value for each term, then, of course, the memory usage is not quadratic. In general, though, you are correct and the memory usage is O(n^2).

That's actually the tracing facility, not the debugger. The debugger is an interactive tool, see ?debugger.

That's actually the tracing facility, not the debugger. The debugger is an interactive tool, see ?debugger.

Consider using fsolve. By using the 'avoid' option you can readily find both roots:

eq := 1+(5*x)*(log(5*x)-1)=1/2*v-sqrt(k)*x:
feq := eval(eq, [k=.98, v=.4]):
x1 := fsolve(feq,x,0..1);
                              x1 := 0.2019811135

x2 := fsolve(feq,x,0..1,avoid={x=x1});
                              x2 := 0.1288902502

Note that the GraphTheory package, which is new for Maple 11, has a MinimalSpanningTree function that uses Kruskal's algorithm. There is also a PrimsAlgorithm function, which uses, naturally, Prim's algorithm to compute a minimal spanning tree. The older networks package has a spantree function that uses Prim's algorithm.

Excellent question. In both cases the r is a symbolic argument. However, the definition of the sin procedure is such that if it gets a symbolic argument (say x) it returns the unevaluated function sin(x). You can inspect the sin procedure by typing

interface(verboseproc=2):
print(sin);

The portion that returns the unevaluated function is a bit tricky. A somewhat clearer example is exp. We can use the showstat procedure to examine the last couple of lines:

showstat(exp, 57..58);
exp := proc(x::algebraic)
local res, i, t, q, n, f, r;
       ...
  57     res := ('exp')(x)
       end if;
  58   exp(args) := res
end proc

Here you can see that the local variable res is assigned ('exp')(x); the forward quotes prevent the procedure from being evaluated. The final line returns the previously assigned res, but also directly inserts this value into the remember table for the procedure. That way, a second call to exp with the same symbolic arguments avoids the computation and just looks up the result. The reason that the symbolic argument fails with the original assignment to T is that it does not know how to handle symbolic arguments; more specifically, the Optimization:-Maximize procedure cannot deal with the particular symbolic arguments it received. Adding the conditional that I suggested avoids passing symbolic args to Maximize, instead returning an unevaluated call to T. That works because the unevaluated call is then passed to plot, which, when it evaluates the expression at particular points, replaces the symbolic argument with a numerical value and evaluates the result.

Excellent question. In both cases the r is a symbolic argument. However, the definition of the sin procedure is such that if it gets a symbolic argument (say x) it returns the unevaluated function sin(x). You can inspect the sin procedure by typing

interface(verboseproc=2):
print(sin);

The portion that returns the unevaluated function is a bit tricky. A somewhat clearer example is exp. We can use the showstat procedure to examine the last couple of lines:

showstat(exp, 57..58);
exp := proc(x::algebraic)
local res, i, t, q, n, f, r;
       ...
  57     res := ('exp')(x)
       end if;
  58   exp(args) := res
end proc

Here you can see that the local variable res is assigned ('exp')(x); the forward quotes prevent the procedure from being evaluated. The final line returns the previously assigned res, but also directly inserts this value into the remember table for the procedure. That way, a second call to exp with the same symbolic arguments avoids the computation and just looks up the result. The reason that the symbolic argument fails with the original assignment to T is that it does not know how to handle symbolic arguments; more specifically, the Optimization:-Maximize procedure cannot deal with the particular symbolic arguments it received. Adding the conditional that I suggested avoids passing symbolic args to Maximize, instead returning an unevaluated call to T. That works because the unevaluated call is then passed to plot, which, when it evaluates the expression at particular points, replaces the symbolic argument with a numerical value and evaluates the result.

If you come with some really great features, let me know and I'll consider adding them to the emacs code. I just modified it today to handle some newer constructs of Maple. The pretzel parser has been on hold, mainly 'cause I injured my back and haven't felt like working on extra projects just now, but also 'cause parsing the angle brackets has been problematic. I took a look at it last weekend and may have go that part working. Debugging yacc grammars isn't my forte. I'll try to post a sample of what it does with typical input.

If we interpret the position as a location on the complex plane, then I believe the differential equations are equivalent to the reasonably simple first-order equation:

 z' = -s*(z-c)/|z-c|, with c = exp(i*t) and z(0) = 0

That doesn't help with a symbolic solution.

If we interpret the position as a location on the complex plane, then I believe the differential equations are equivalent to the reasonably simple first-order equation:

 z' = -s*(z-c)/|z-c|, with c = exp(i*t) and z(0) = 0

That doesn't help with a symbolic solution.

An obvious application is the one that Paulina used to introduce this blog, adding a typeset a caption to a plot. I would find it useful to be able to do plot(..., caption=TeX("2\\cdot(x+y)"))—where TeX is a TeX to MathML converter—rather than having to use 2D input and the mouse.

You need to learn the mathml format. For something like that, it is too complicated to quickly type:

> 2*(x+y); # convert to atomic using Paulina's instructions
                                2*(x+y)
> lprint(%);
`#mrow(mn("2"),mo("⋅"),mfenced(mrow(mi("x"),mo("+"),mi("y"))))`