I agree that it has been beaten to death, in the sense that most everything
that needs to be said may have been said. But your example suggests that
you are still trying to do things that need not, and probably should not be
done. Stavros pointed out that substitution semantics is much cleaner, and
ev should NOT be used unless you really mean to evaluate. For example
converting "noun" forms to "verb" forms in differential forms. Merely
putting values in for symbols can and should be done by substitution, at
least if you want to be careful.
Or you can write programs in Lisp, whose semantics are rather more carefully
set out. By tradition, Lisp has a function "eval", and it is generally
conceded that any (modern) Lisp program that call eval explicitly is
extremely suspect. Novices use eval almost always wrong. When an advanced
programmer uses eval (once in a hundred pages of code?), it tends to be
surrounded by a block of comments explaining why this is excusable. (e.g.
see Norvig's Paradigms of AI Programming).
Using ev in Maxima has much the same problem as lisp's eval.
Technically speaking lisp's eval needs 2 arguments: a form to be evaluated,
say (+ a b), and an environment such as one that binds a to 3 and b to 4.
Or a partial environment in which one or both are unbound and their values
found in a global environment. Maxima messes with this concept because
there are other tricks: if a symbol has no binding then it is implicitly
bound to itself ("quoted").
And there are other hazards including functions which are "nounified" and
"verbified". Also, chains of bindings are unraveled by repeated ev's. Also
see "infeval". Please be assured that noun, verb, infeval, were not part of
the original design, but were added out of some apparent necessity, to
encode certain constructs like unevaluated limits, integrals, derivatives,
etc. Using this when NOT necessary is asking for trouble. And this is not
just Maxima. People writing code in Mathematica have to deal with Hold,
HoldFirst, Release, and other uncomfortable features.
RJF
> -----Original Message-----
> From: maxima-bounces at math.utexas.edu
> [mailto:maxima-bounces at math.utexas.edu] On Behalf Of Michel
> Van den Bergh
> Sent: Monday, January 01, 2007 9:53 AM
> To: Richard Fateman; maxima at math.utexas.edu
> Subject: Re: [Maxima] remvalue, was: Strange plot2d behaviour
> (correction)
>
> Dear Richard,
>
> This has now been beaten to dead. Try
>
> h(s, t) := ev(subvar(s, t), eval);
>
> h(t[4],1);
>
> Answer:
> t evaluates to 1
> Improper name or value in functional position.
> #0: h(s=t[4],t=1)
> -- an error. To debug this try debugmode(true);
>
> The following is a mechanical fix
> h(s, t) := block([s__, t__], s__ : s, t__ : t, remvalue(s, t),
>
> ev(subvar(s__, t__),
> eval))
>
> h(t[4],1);
>
> (t_4)_1
>
> Of course I assume that the user will not use the variables s__, t__.
> s__, t__
> should really be unique. If you can give me a (generic!) solution with
> ?gensum()
> I will be happy to learn it.
>
> But the fact remains is that I don't see why maxima interpreter cannot
> do this for us.
> In my opininion parameters are parameters and local variables
> are local
> variables. There should
> be ***no*** side effects ***at all***.
>
> Michel
>
> >
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>