Stavros Macrakis wrote:
>>I think I'd need a thourough understanding of rat before
>>tackling this bug. Stavros?
>
>
> I don't know the rat package well at all! -- I just read code as
> necessary.
>
> Richard Fateman, on the other hand, was responsible for the Rat package
> when he was at MIT.
>
> -s
>
I can't claim responsibility for the hacks added to make taylor
series work. That's Rich Zippel's stuff.
The varlist /genvar list correspondence has often been a source
of bugs, as well as a certain kind of power. Allowing different
variable to be "more main" in different expressions in the same
system is useful, but maybe could be done differently.
The idea, as you probably realize, is to rename "non-rational"
kernels in polynomial-like arithmetic. so instead of having
to fool with sin(x), exp(x), ....
you fool around with generated GENSYMS like g0002, g0003 ...
and there are 2 lists maintaining their correspondence. But
sometimes I guess people maintain this correspondence with
disrep properties for different purposes.
The advantage of the 2 lists is that it is part of the data
that is bound with the rat form, so different bindings are
possible, as stated above.
((mrat simp ($x $y (($sin simp) $x) ....) (g001 g002 g003 ....)
stuff...)
also note that there are sticky parts involving
rational forms where the kernels are subtlely dependent
e.g. exp(x), exp(y), exp((x+y)/2) should not have 3 gensyms.
It is possible that in a world with much more memory, things
should be done differently.
The ordering predicate for gensyms, named pointergp was
orginally intended to be superfast. You make a bunch of gensyms.
Then you sort them by the positions they occupy in symbol
table memory, and then to compare them you see which pointer
is greater. But with a copying GC, the relative position
of pointers may change. So the comparison is done by
some portable computation.
RJF