Let me understand this better. (1) -> f(n)==(free k; k:=k+1; n+k); Type: Void (2) -> f(1) Loading /usr/lib/axiom-20050201/algebra/UPMP.o for package UnivariatePolynomialMultiplicationPackage Compiling function f with type PositiveInteger -> Polynomial Integer Compiled code for f has been cleared.
(2) k + 2 Type: Polynomial Integer (3) -> f(1) Compiling function f with type PositiveInteger -> Polynomial Integer (3) k + 3 Type: Polynomial Integer (4) -> f(1) (4) k + 4 Type: Polynomial Integer First of all, why does it claim to have compiled the function twice? Why does it claim after line 2 that "compiled code for f has been cleared"? The "free" statement declares k to be in the global namespace, yet when it is assigned in f(), the output does not seem to know that it is a global with a bound value...??? A similar function in Mathematica: f[n_] == Block[{}, (k:=k+1; n+k)] complains that "Recursion depth of 256 exceeded" which makes more sense because it is searching for a definition of k. (actually it makes that complaint even if I define k first -- I think I've not written an equivalent example) And the moral of the story is that side-effects suck. Lisp and the lambda calculus have the right idea... ;) A dependency tree for such an example would probably look like this (for your example below): line 6: depends on n from line 5, k from line 4; modifies: k line 5: depends on nothing ; modifies: n line 4: depends on n from line 3, k from line 1; modifies: k line 3: depends on nothing ; modifies: n line 2: depends on nothing ; modifies: f line 1: depends on nothing ; modifies: k Searching the dependency tree for after modifying line 5 would reveal: line 6 must be recomputed because it depends on line 5 (modified) line 5 must be recomputed because it was modified line 4 must be recomputed because line 6 depends on k from line 4 line 3 must be recomputed because it modifies n which is used on line 4 line 1 must be recomputed because line 4 depends on k from it. and the minimum set of recomputations is lines 1,3,4,5,6 in that order. As in my earlier example, the dependency tracker must keep track of which inputs modify which variables. But, I do not think it necessary to cache their values. Caching could be done for speed, but I think needs more debate... Ralf Hemmecke [EMAIL PROTECTED] wrote: > Axiom also allows to do something like that... > What should the line (6) f(n) return after a user modified line (5) to > n:=3? Will f(n) return 6 or 7? And what did the user expect? > > Ralf > > (1) -> k:=1 > > (1) 1 > Type: > PositiveInteger > (2) -> f(n)==(free k; k:=k+1; n+k); > > Type: Void > (3) -> n:=2 > > (3) 2 > Type: > PositiveInteger > (4) -> f(n) > Compiling function f with type PositiveInteger -> PositiveInteger > > (4) 4 > Type: > PositiveInteger > (5) -> n:=2 > > (5) 2 > Type: > PositiveInteger > (6) -> f(n) > > (6) 5 > Type: > PositiveInteger > > > > > _______________________________________________ > Axiom-developer mailing list > Axiom-developer@nongnu.org > http://lists.nongnu.org/mailman/listinfo/axiom-developer -- Cheers, Bob McElrath [Univ. of California at Davis, Department of Physics] "One of the best ways to get yourself a reputation as a dangerous citizen these days is to go about repeating the very phrases which our founding fathers used in the great struggle for independence." --Charles A. Beard
signature.asc
Description: Digital signature
_______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer