[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] Lazy re-evaluation (was: More AxiomUI)
From: |
Bob McElrath |
Subject: |
Re: [Axiom-developer] Lazy re-evaluation (was: More AxiomUI) |
Date: |
Wed, 22 Jun 2005 11:14:54 -0700 |
User-agent: |
Mutt/1.5.6+20040523i |
First let me give a simple definition of lazy re-evaluation. Imagine a
worksheet interface, that when read from top to bottom, is *always*
consistent. In Maple and Mathematica the user must remember what he has
executed, and keep much information about the kernel's state in his/her
head. It is very easy to miss that an output block has changed and
should be re-evaluated. This state information is easy to keep and deal
with in axiom itself, and would *never* make mistakes. A user with a
1000 input worksheet will surely make a mistake about which output lines
need re-evaluation sooner or later. I certainly do. But then, I'm a
world-renowned software-breaker.
William Sit address@hidden wrote:
> I am not sure what you meant by "lazy re-evaluation" here (or it could be my
> ignorance about the concept). Mathematica has two modes of assignments:
> SetDelayed (:=) for functions and Set (=) for immediate evaluation and so does
> Axiom: macro (==) and assign (:=). Both SetDelayed and macro can be used to
> define *any* identifier, not necessarily a function (just think of it as
> function without arguments although there may be a minor difference: "x ==
> ..."
> instead of "x() == ..."). Each time an identifier defined using SetDelayed or
> macro is referenced, it is recomputed in Set or assignment (and in SetDelayed
> or
> macro when these are computed), and this occurs recursively until all
> identifiers at the "leaves" are resolved with Set or assigned values. The
> SetDelayed or macro defined identifiers have no "values" associated and the
> values are computed on demand. Do you consider this delayed computation lazy
> re-evaluation? [I put "values" in quotation because the word value can have
> different meanings at different levels; at a functional level, the SetDelayed
> or
> macro defined identifiers of course have associated "values".]
Bill pointed out that this is really "lazy evaluation".
I think lazy evaluation also deserves some thought. It could be used to
simulate lazy re-evaluation, but again it forces a full recomputation
each time. Re-evaluation aims to compute as little as possible to
return the worksheet to a consistent state.
The combination of macros/SetDelayed and Eval have always bothered me a
lot. It is generally possible to have multiple levels of this, so that
to compute an expression requires multiple evals:
eval(eval(expression)). Some functions (like Plot) do not evaluate
their argument while most others do.
The situation is highly confusing. I think there may be a smarter way
to do it, implementing lazy re-evaluation, while at the same time hiding
*all* of the SetDelayed/Eval mess from the user. I find myself in a
situation occasionally: "How many times do I have to evaluate this to
get a number?" "Do I need to use evalc() or evalm()?" (evalc and evalm
are Maple's complex and matrix evaluators)
Can anyone think of an example using axiom macros demonstrating a
calculation that cannot be done any other way? Can we think of a way to
map it onto a different paradigm (lazy re-evaluation maybe?) that can
also arrive at the correct answer?
--
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] Lazy re-evaluation (was: More AxiomUI), Page, Bill, 2005/06/21
- Re: [Axiom-developer] Lazy re-evaluation (was: More AxiomUI), William Sit, 2005/06/22
- Re: [Axiom-developer] Lazy re-evaluation (was: More AxiomUI),
Bob McElrath <=
- RE: [Axiom-developer] Lazy re-evaluation (was: More AxiomUI), Page, Bill, 2005/06/22
- RE: [Axiom-developer] Lazy re-evaluation (was: More AxiomUI), Page, Bill, 2005/06/23
- RE: [Axiom-developer] Lazy re-evaluation (was: More AxiomUI), Page, Bill, 2005/06/23
- Re: [Axiom-developer] Lazy re-evaluation (was: More AxiomUI), William Sit, 2005/06/23
- Re: [Axiom-developer] Lazy re-evaluation (was: More AxiomUI), William Sit, 2005/06/23