I think that it might be useful to have a $pushS and a $popS in lisp
that worked solely on global lisp symbols like L which were
bound to expressions of the form L = ((mlist simp) a b c ....) if
there is a time-critical application.
where pushS(d, L) made L into ((mlist simp) $d a b c ...)
and popS(L) made L into ((mlist simp a b c) and returned $d
It would also be easy to write.
Now the question is: should pushS and popS do all the checking needed
to validate the assumptions and if they are not valid, do "the other
stuff"?
How can we check that L is a global lisp symbol, anyway?
RJF
Stavros Macrakis wrote:
> On Tue, Sep 8, 2009 at 9:59 AM, ?iga Lenar?i?<ziga.lenarcic at gmail.com> wrote:
>
>> On Sep 8, 2009, at 3:22 PM, Stavros Macrakis wrote:
>>
>>> It is an error to use Lisp's push function to modify a Maxima
>>> variable. In particular, this means you can't push onto a subscripted
>>> variable: zz[1]:[]$ push(3,zz[1]) => error.
>>>
>> Ah, these are the cases I always forget about, because accessing a maxima
>> variable that is also a lisp variable is so easy to do. So in this case I
>> can get the attached list with 'meval', modify it, but how do I then attach
>> it back to the zz[1]?
>>
>
> Good question. Another interesting question is whether the push
> variable should be evaluated twice. Consider:
>
> push( 3, x[i:i+1] )
>
> Surely you don't want this to be equivalent to
>
> x[i:i+1] : cons(3, x[i:i+1])
>
> which assigns to a different array location than the one from which it
> reads, but rather something like
>
> ( temp: (i:i+1), x[temp]: cons(3, x[temp] ) )
>
> This sort of mess is perhaps one reason that push is not part of the
> standard Maxima core.
>
>
>> One way is probably by constructing a 'mset' expression and evaluating it,
>> but can we use something cheaper in this case (since it is known what we
>> want)?
>>
>
> Why would you construct an mset expression? There is already an mset
> function in mlisp.lisp.
>
>
>> To make a fast push/pop I would still have special code, when push/pop gets
>> a 'symbolp' (regular Maxima variable). In this case it's probably OK to just
>> use lisp's 'set'?
>>
>
> This is a bad idea for two reasons: 1) it makes your code unnecessary
> complicated; 2) it duplicates the same functionality in two places.
> The second is the really crucial point. If at some point the
> semantics of mset change (e.g. because we change scoping rules or
> whatever), how will the maintainer know that he/she should also change
> your push/pop functions? And are they really that slow?
>
> -s
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>