[Axiom-developer] Patches (?) for sum/product and sqrt

[m.rubey]

last weekend I tracked down two of the bugs I reported. However, the way to fix
one of them is not completely clear to me. (The other one I submitted as a
patch) Therefore, I'd like to discuss it here first...

[bugs #9057] product over product or sum fail

The problem is that

(2) -> product(summation(i,i=1..j),j=1..1)
 
   >> Error detected within library code:
   not a kernel

protected-symbol-warn called with (NIL)

or, even shorter,

(2) -> eval(summation(i,i=1..%A),%A,1)
 
   >> Error detected within library code:
   not a kernel

protected-symbol-warn called with (NIL)

in fact, anything but %A works in the line above. Obviously, this is a problem
of variable capture. Internally, summation(f(i),i=1..j) is represented as the
operator %defsum with arguments [f(%A),%A,i,1,j]. For some reason, the
author of the package introduces a dummy variable %A, which represents the
summation index. Since the same dammy variable is used for all sums and
products, there is a problem when we nest them or when the summation bound is
"bad". The offending line product(summation(i,i=1..j),j=1..1) is represented as

%defprod with arguments [%defsum with arguments [%A,%A,i,1,%A],%A,j,1,1]

and, when evaluating it, axiom substitutes 1 for %A in the inner list. Then it
tries to evaluate %defum with arguments [1,1,i,1,1] which leads to an error,
because AXIOM expects the second element of the list to be a symbol...

A possible fix is to introduce a new dummy variable for each sum and
product. However, I did not *quite* manage to do so, since AXIOM does not seem
to care about which symbols are already around:

(1) -> %A::SYMBOL

   (1)  %A
                                                                 Type: Symbol
(2) -> new()$SYMBOL

   (2)  %A
                                                                 Type: Symbol
(3) -> G1419::SYMBOL

   (3)  G1419
                                                                 Type: Symbol
(4) -> symbol(GENSYM()$Lisp)

   (4)  G1419
                                                                 Type: Symbol

Anyway, in the submitted patchfile, I did this.

In fact, I do not really understand why this dummy variable is needed...

While reading the package COMBF I stumbled over annother bug. The following is
used as rule for differentiating sums:

    dvdsum(l, x) ==
      x = retract(y := third l)@SE => 0
      k := retract(d := second l)@K
      differentiate(h := third rest rest l,x) * eval(f := first l, k, h)
        - differentiate(g := third rest l, x) * eval(f, k, g)
             + opdsum [differentiate(f, x), d, y, g, h]

Although this -- d/dx sum_i^x f(i) = f(x) -- is a nice try, it is wrong. It
seems that the order of magnitude is roughly correct, but that's about it. 

Martin