First of all, could you check whether the bug occurs also in the
commercial Macsyma? Maybe this would help...
> I don't know why this disrep property is used outside the $ratdisrep
> program.
Sorry, it seems that I have to revise my statement a little: although the
disrep property is used and set in hayat, it does so only at very special
places: in taylor1, together with the following comment
;; 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).
in setup-multivar-disrep (this is the most suspicious place), together
with the following comment, which I do not really understand:
;; All genvar's corresponding to internally generated
;; multivars must "disappear" when disrep'd. If this
;; were not done then disrep'ing gx*gt would give x*t
;; which, upon, re-tayloring would give (gx*gt)*gt,
;; where t is the internal multivar for x, and gt, gx
;; are their genvars. An example where this would occur is
;; taylor(sin(x+y),[x],0,f1,[y],0,1).
and in re-taylor, which is called by taylor2
;; Put back the old disrpes so rcdisrep's will work correctly.
...
;; Restore the correct disreps.
and some other places, which I do not find suspicious (because it has
to do with the kernel, i.e. a gensym for x-pt...
To be more specific, please follow:
bugprint prints a list (varlist (genv1 DISREP-prop1) (genv2 DISREP-prop2) ...)
(defun fpolysum (e) ;returns *ans*
(bugprint "fpolysum")
(let ((a (fpoly1 (setq e ($expand ($ratdisrep ($rat e *var*))))))
(b) ($prederror))
(bugprint "fpolysum")
taylor(sum(M^K*sum(L^K,L,1,D),K,1,INF),M,0,1),simpsum;
... this is the first time fpolysum is invoked, i.e., for K=1 ...
(1 ENTER FPOLYSUM ($L))
("fpolysum"
(((%SUM SIMP)
((MTIMES SIMP) ((%SUM SIMP) ((MEXPT SIMP) $L $K) $L 1 $D)
((MEXPT SIMP) $M $K))
$K 1 $INF)
$M)
((#:|'SUM(('SUM(L^K,L,1,D))*M^K,K,1,INF)21808|
((%SUM SIMP)
((MTIMES SIMP) ((%SUM SIMP) ((MEXPT SIMP) $L $K) $L 1 $D)
((MEXPT SIMP) $M $K))
$K 1 $INF))
(#:M21808 $M)))
Which is (in my opinion all very nice. After fpoly is set, bugprint shows
the following:
("fpolysum"
(((%SUM SIMP)
((MTIMES SIMP) ((%SUM SIMP) ((MEXPT SIMP) $L $K) $L 1 $D)
((MEXPT SIMP) $M $K))
$K 1 $INF)
$M)
((#:|'SUM(('SUM(L^K,L,1,D))*M^K,K,1,INF)21808| $L) (#:M21808 $M)))
now the disrep property of the "funny" genvar doesn't correspond to the
varlist symbol anymore. (No hayat stuff involved here) I tried to read
rat3e.lisp, and if I understood then $rat just looks whether there are
"enough" genvars available on genvar, only if this is not the case, it
produces new genvars:
(C1) rat(x);
(D1)/R/ x
(C2)
MAXIMA>>(defun buglist () (list varlist (mapcar #'(lambda (v) (list v (get
v 'DISREP))) genvar)))
MAXIMA>>(buglist)
((|$x|) ((#:|x21773| |$x|)))
MAXIMA>>:q
(C2) rat(y);
(D2)/R/ y
(C3)
MAXIMA>>(buglist)
((|$y|) ((#:|x21773| |$y|)))
However, here the varlist also is changed, whereas in fpolysum, this is
not the case. (BTW, the DISREP property seems to be set only if the result
is printed, i.e. rat(x)$ doesn't set the disrep property...)
Well, in any case, this is only the top of the iceberg, because the second
time fpolysum is invoked (now with K=2)
(1 ENTER FPOLYSUM (((MEXPT SIMP) $L 2)))
("fpolysum"
($D ((%SUM SIMP)
((MTIMES SIMP) ((%SUM SIMP) ((MEXPT SIMP) $L $K) $L 1 $D)
((MEXPT SIMP) $M $K))
$K 1 $INF)
$M)
((#:D21809 $D) (#:|'SUM(('SUM(L^K,L,1,D))*M^K,K,1,INF)21808| $L)
(#:M21808 $M))
here the DISREP property of the sum is already strange, in fact it stayed
the same since the first fpolysum. After the ($expand ($ratdisrep ($rat e
*var*))) in fpolysum, we get
("fpolysum"
($D ((%SUM SIMP)
((MTIMES SIMP) ((%SUM SIMP) ((MEXPT SIMP) $L $K) $L 1 $D)
((MEXPT SIMP) $M $K))
$K 1 $INF)
$M)
((#:D21809 $L) (#:|'SUM(('SUM(L^K,L,1,D))*M^K,K,1,INF)21808| $L)
(#:M21808 $M)))
Note however that the varlist / genvar correspondence stays always "good".
Trouble arises only because when taylor_simplify_recurse is invoked, it
eventually rcdisrep's (= cdisrep's) its argument ps which returns the
wrong answer.
Only, I cannot believe that it is "good" to have something on the DISREP
property which does not correspond to varlist...
Is it possible that the bug really is to be found in
($expand ($ratdisrep ($rat e *var*)) ?
Could this be related to the comment in taylor1 I cited above? Again:
;; 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).
-------------------------------------------------------------------
> >>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.
what do you mean with "sticky parts"?
Martin