Another issue: in parallel search, you need to define what happens in
overlapping cases.
Currently, we have:
psubst([x=y,f(x)=z],f(x)) => f(y)
psubst([f(x)=z,x=y],f(x)) => z
which is wrong: the semantics of *parallel* substitution should be
independent of order. The current behavior is an artifact of the hacky
implementation of psubst. This can't happen with sublis because it is
limited to symbols (not even subscripted variables).
The two obvious semantics are outside-in and inside-out. Outside-in seems
better to me, though I guess we could have a bottomup parameter as in
scanmap.
-s
On Wed, Jun 26, 2013 at 2:58 PM, Stavros Macrakis <macrakis at alum.mit.edu>wrote:
> On Wed, Jun 26, 2013 at 2:19 PM, Robert Dodier <robert.dodier at gmail.com>wrote:
>
>> On 2013-06-23, Barton Willis <willisb at unk.edu> wrote:
>>
>> > The function sublis controls evaluation of lambda forms using mqapply
>> > (not mquote):
>>
>> Thanks for the reminder -- I had forgotten about that.
>>
>> > (%i3) sublis(['sin =3D lambda([x],42)], sin(z)), sublis_apply_lambda :
>> false;
>> > 1> (MSUBLIS-SUBST ((%SIN SIMP) $Z) T)
>> > 2> (MSUBLIS-SUBST ($Z) NIL)
>> > 3> (MSUBLIS-SUBST $Z T)
>> > <3 (MSUBLIS-SUBST $Z)
>> > 3> (MSUBLIS-SUBST NIL NIL)
>> > <3 (MSUBLIS-SUBST NIL)
>> > <2 (MSUBLIS-SUBST ($Z))
>> > 2> (MSUBLIS-SUBST %SIN T)
>> > <2 (MSUBLIS-SUBST ((LAMBDA SIMP) ((MLIST) $X) 42))
>> > <1 (MSUBLIS-SUBST ((MQAPPLY) ((LAMBDA SIMP) ((MLIST) $X) 42) $Z))
>> > (%o3) lambda([x],42)(z)
>>
>> > Maybe $substitute could be modified to use the mqapply trick.
>>
>> Yeah -- I've been working on that. But I wonder if subst and sublis
>> should be merged -- aside from sublis being parallel and subst being
>> serial, do they have any different effect? If we are satisfied that
>> they are otherwise the same, we could nuke the existing subst and
>> have it punt to sublis instead (looping to get serial substitutions).
>
>
> Agreed: subst/psubst/sublis should be one function internally. sublis
> will have to be reworked to use hash tables rather than symbol property
> lists because subst is not restricted to symbols, e.g., subst(x,a*b,f(a*b)).
>
> > As for extending the (obscure) option variable sublis_apply_lambda
>> > to substitute, I dunno--generally I lean toward fewer (obscure)
>> > option variables.
>>
>> Agreed -- I'm inclined to nuke sublis_apply_lambda.
>>
>
> We will need some mechanism to force the transformation
> lambda([x],f(x))(y) => f(y). ev(...,lambda) is the obvious convenience
> syntax, but I would like to have the functionality be available outside ev,
> e.g. lambda_subst(expr).
>
> > Is mqapply used this way a crazy hack that just happens to wrork?
>>
>
> ? What crazy way? The whole point of mqapply is to allow non-symbols to
> be applied to arguments. The crazy part is that Maxima lets you get away
> with a lambda-expression in the caar sometimes.
>
> -s
>
> Looks to me like it is working just as one would expect.
>>
>> best
>>
>> Robert Dodier
>>
>> _______________________________________________
>> Maxima mailing list
>> Maxima at math.utexas.edu
>> http://www.math.utexas.edu/mailman/listinfo/maxima
>>
>
>