Re: [Maxima-discuss] A question about parsing: ":lisp #$expr$" is not low-level enough

[Stavros M. <mac...@al...>]

I wish you'd explained your use case earlier -- we could have helped you
more effectively.

You do not need to use *both* *simp:false* and *lambda(...). *For this
example, I would do something like this:

dosimp(ex):=block([simp:true],expand(ex,0,0))$    << simplifies without
evaluating
doeval(ex):=block([simp:false],?meval(ex))$      << evaluate without
simplifying, using internal eval function
fulleval(ex):= block([simp:true], ?meval(ex))$   << evaluates and simplifies
simp:false$    << set globally

q: '( integrate(f(x), x, a, b) = F(b)-F(a) )$

qs: subst([a=43,b=99],q);
doeval(qs);

qr: subst([a=43,b=99, f=lambda([x],3*x^2), F=lambda([x],x^3) ], q);
doeval(qr);
dosimp(%);

You might be interested to see what *integrate* gives as an anti-derivative
with simplification off:

integrate(3*x^2,x);
dosimp(%);


Does this help?

                 -s

On Fri, Jan 14, 2022 at 1:01 AM Eduardo Ochs <edu...@gm...> wrote:

> Nifty!!!!!!! =) =) =)
>
> My use case is very atypical. In my classes I have many students who
> have very little practice with using variables - really! It's sad &
> scary - and when these students have to take a formula and perform a
> substitution on it to obtain a particular case they usually make a big
> mess... for example, they often substitute only certain occurrences of
> the variables, and leave the other ones unsubsituted. And when they
> have to perform substitutions on theorems, propositions, or proofs the
> mess is even bigger...
>
> So: I'm trying to teach them that substitution and simplification _can
> be treated_ as separate operations, and when we keep them as separate
> steps our calculations become much easier to debug... We're doing that
> on paper, and I told them that I believe that all decent programs for
> Computer Algebra should be able to perform substitution in a purely
> syntactical way, without simplification, _if we call the right
> low-level functions in them_. With your trick I'm almost there... try
> this:
>
>   simp:false;
>   to_lisp();
>     (defun $displr (lambdaexpr) (displa (caddr lambdaexpr)))
>     (to-maxima)
>   q: lambda([foo], ('integrate(f(x), x, a, b) = F(b) - F(a)));
>   displr(q)$
>   displr(subst([a=42, b=99], q))$
>   displr(subst([a=42, b=99, f(x)=3*x^2, F(x)=x^3], q))$
>   displr(subst([a=42, b=99, f(x)=3*x^2, F=lambda([x],x^3)], q))$
>
> In the last two lines I'm trying to replace all occurrences of F(expr)
> by expr^3, but I haven't found the right trick yet...
>
>   Cheers and probably thanks in advance =),
>
>   Eduardo Ochs
>     http://angg.twu.net/eev-maxima.html
>
> On Thu, 13 Jan 2022 at 11:11, Stavros Macrakis <mac...@al...>
> wrote:
>
>> Simplification does not happen as a separate step after evaluation of the
>> whole expression.
>> Every subexpression that is evaluated is immediately simplified. Maxima
>> couldn't possibly work otherwise.
>>
>> Obviously we need to be review our documentation more carefully to keep
>> such howlers out!
>>
>> Using :lisp #$ ... $ seems pretty roundabout. To turn off simplification,
>> set *simp:false*. To prevent evaluation, use *'( ... )*. To show the
>> internal form of something, use *?print(...)*.
>>
>> Here's a neat trick: within *lambda* expressions (as well as named
>> function definitions), neither simplification nor evaluation is performed,
>> so *q: lambda([simp], ?print(2+2)) *might help you see how things work;
>> look at *q*, and call *q(false) *and *q(true)* .
>>
>>