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