axiom-developer
[Top][All Lists]

## Re: [Axiom-developer] Lazy re-evaluation (was: More AxiomUI)

 From: Bob McElrath Subject: Re: [Axiom-developer] Lazy re-evaluation (was: More AxiomUI) Date: Thu, 23 Jun 2005 11:41:07 -0700 User-agent: Mutt/1.5.6+20040523i

```Let me understand this better.
(1) -> f(n)==(free k; k:=k+1; n+k);
Type: Void
(2) -> f(1)
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

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...

> 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
> 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