[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] Patches (?) for sum/product and sqrt
From: |
m.rubey |
Subject: |
[Axiom-developer] Patches (?) for sum/product and sqrt |
Date: |
Tue, 25 May 2004 14:21:38 +0200 (CEST) |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Axiom-developer] Patches (?) for sum/product and sqrt,
m.rubey <=