I am going to be away from email for a while, and can't even think
about this question thoroughly now.
I think that redefining cdisrep is a good strategy. This lookup
does not happen so often.
Commercial Macsyma does not exhibit this problem, by the way.
I think that making new
gensyms would not be that terrible, although they could pile up and
fill all of memory if you did it too much!
Yes, it is ok to call me Richard. ( Here in California even total
strangers call you by your first name!)
Martin RUBEY wrote:
> On 9 Feb 2003, Wolfgang Jenkner wrote:
>
>
>>Martin RUBEY <rubey@labri.fr> writes:
>>
>>
>>>It seems that there are 2 1/2 solutions to the varlist/genvar problem:
>>
>>[...]
>>
>>>2. Solution
>>
>>[...]
>>
>>>progbind varlist and genvar at all "entrypoints" to programs that use $rat
>>>or friends.
>>
>>I agree with this one except for the `all'.
>>
>>I think the fundamental paradigm in the rat3e module goes like this:
>>
>>1) Locally bind VARLIST (but not necessarily GENVAR since it is meant
>> to be a pool of symbols).
>
>
> Well, unfortunately this is not sufficient in the hayat/combin interaction
> (I checked, only binding varlist in fpolysum gives the wrong answer)
> The low-level reason for this is that in
>
> (defun taylor_simplify_recurse (ps)
> (if (pscoefp ps) (taylor2 (funcall taylor_simplifier (rcdisrep ps)))
> ...
> (if you are interested in the details, please tell me, I think I
> understand hayat and combin to some extent meanwhile...)
>
> rcdisrep (= cdisrep, see mhayat) is called on some genvar. And for some
> reason, cdisrep returns whatever is on the disrep property of the genvar,
> disregarding the varlist.
>
> rcdisrep is called very often in hayat (~ 30 times, I suspect this is for
> efficiency? ), and there are lots of comments I do not understand fully...
> Furthermore they refer to a bug database we do not seem to have.. (For
> example the following in taylor1:
>
> ;; This drastic initialization ensures that ALGEBRAIC, TELLRAT, DISREP,
> ;; etc. prop's are removed from our gensyms. RATSETUP does not appear
> ;; to do this correctly, e.g. see ASB's bug of 1/10/83 (MQUERY 17).
>
>
>>2) Let NEWVAR and RATREP* establish the correspondence between
>> VARLIST and GENVAR.
>>3) Forget the correspondence and let your algorithm work on the body
>> of the resulting CRE form.
>
>
> Trouble seems to arise when an external program (such as simpsum in "my"
> case) uses $rat or friends which might put something on the disrep
> property.
>
>
>>4) Do something sensible with the result.
>>
>>Now, apparently hayat has it's own way of handling the VARLIST/GENVAR
>>correspondence, which either does not mesh perfectly with this
>>paradigm or triggers some bug in the rat3 module.
>>
>>Frankly, I don't know why, e.g., $GCD binds GENVAR and $CONTENT does
>>not. So I think the first step would be to understand when it is
>>necessary to locally bind GENVAR.
>
>
> Yes.
>
> However, I think that binding genvar and varlist allways but in special
> cases might be the right approach. Maybe even omit "special" cases. In
> fact, I do not understand quite why keeping the genvars should save much
> time. Does it cost so much to create a new symbol?
>
> Thanks for your interest, Richard (may I call you Richard?) and Wolfgang,
> I already felt a little lost!
>
> Martin
>
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima