My feeling is that the complexity of buildq is not worth
learning because simpler methods almost always do what
is needed. It is not that many simpler methods together
are a replacement for buildq. It seems to me it is the same
simpler method. And buildq is very hairy.
if one needs to compute the body of a function,
and then "do the definition": then here is a way to do it...
body: subst([a=5, b=3], a*x+b) ; /* or sublis.. perfectly clear
substitution semantics */
define (f(x),body); /* not quite as clear because the first arg is not
eval'ed */
/* all done? */
/* will not work...
head: 'f(x); define(head,body);
*/
/* will work */
(define (''head, body)
As far as interpolating using Lagrange interpolation formula
here is a 2-line version that works ONLY with dynamic scope...
p(j,z,n):=y[j]*prod((z-x[k])/(x[j]-x[k]),k,1,j-1)*prod((z-x[k])/(x[j]-x[k]),k,j+1,n);
doit(x, y, n) := sum(p(i,z,n),i,1,n);
/* to see it work, try */
doit([1,2,3],[1,4,9],3) /* 3 points, should become z^2. */
ratsimp(%);
define(my_interp_fun(z),%);
Now you may object to my using the symbol "z", but that too could be fed
in to doit.
e.g.
doit(x, y, n, z) := sum(p(i,z,n),i,1,n);
and then
doit([1,2,3],[1,4,9],qq);
Finally, it is true that there will be confusion if you use these exact
programs
with your own names that are the same as the names here, e.g. x and y
and p, and i, and j.
These can usually be "fixed" by making functions names slightly more
devious.
A cleaner solution would be to do it "right" with lexical scope, or
with passing the arrays of x and y values in to p as parameters.
The problem with a buildq solution is it might be more deviously wrong. :)
RJF
Robert Dodier wrote:
>On 12/12/05, Stavros Macrakis wrote:
>
>
>
>>Well, the first reason is I suppose aesthetic: that this is the 'wrong
>>way'; the right way would be true lexical scoping (but that has lots
>>of difficulties in the Maxima context, which have been discussed
>>before). So perhaps that is not such a good reason.
>>
>>
>
>i agree that lexical scoping would be really nice.
>
>
>
>>Another reason is that as a general rule, it is a bad idea to use
>>strong mechanisms when weaker ones will do.
>>
>>
>
>i disagree completely. knowing one strong approach
>which solves several problems is much better than
>trying to memorize several weaker approaches.
>
>
>
>>Buildq is intended for building code within macros,
>>not for simply substituting values.
>>
>>
>
>the intent of the programmer is irrelevant to the user.
>i'm frankly mystified by suggestions to the contrary.
>as for myself, i'm glad to hear we have another satisfied customer.
>
>buildq has 2 things going for it: it substitutes in parallel,
>and it quotes its second argument.
>both of these make predicting the outcome easier
>(a nontrivial consideration in maxima).
>neither sublis nor subst have both of these features.
>
>best,
>robert dodier
>