axiom-developer
[Top][All Lists]
Advanced

[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: Thu, 23 Jun 2005 14:48:47 -0700
User-agent: Mutt/1.5.6+20040523i

William Sit address@hidden wrote:
> > > As I commented above, it is *not* Axiom's job to decide for me
> > > what needs recomputing and what does not.
> > 
> > I disagree. To paraphrase what Bob wrote several emails earlier:
> > "Why should it be necessary for me to do something complex
> > like figuring out an efficient re-calculation sequence when
> > this is something that a computer can do very easily?"
> 
> In my case, because *I* want to be in the driver seat. Also by being forced to
> do so, I understand my algorithm much better. The resulting sequence of
> computations will be part of my final algorithm which, for better or worse,
> represents my best effort. No matter how efficient this re-calculation is done
> by the system, I want a repeatable computation; LRE is not repeatable because 
> it
> depends on a history of interaction. See Part III on Maple.

Let me quote: "LRE is not repeatable because it depends on a history of
interaction".  This is exactly opposite of the truth!

A traditional Mma/Maple worksheet is not repeatable because it depends
on the history.  I can go back and re-execute lines out of order,
resulting in a kernel state that is very different than what is written
on the screen, that I must remember!

With LRE the kernel state is represented correctly by what is on the
screen, *no matter what order I entered the commands*.

> This is not the same issue as efficient implementation of recursion, where I
> would *definitely* want the system to handle it.

I disagree.  It's exactly the same issue.

The computer can efficently track, tell you about, and re-evaluate
dependencies, so that the things you have entered (in the *order* they
are placed on the screen) are always accurate, so why not have it do
just that?

Using the previous example f(n)==(free k; k:=k+1;k+n), if at any point I
want to insert f(n) into the middle of my document somewhere, and I want
to know what k is, all I have to do is add at the point I want:
    k
    f(n)
Which will tell me the value of k used.  Note this would not cause
anything above it to be re-evaluated if values are cached, but would
cause any f(n) calls below it to be re-evaluated.  In a simpler example,
I could look two lines above and see what value was assigned to k there.

Due to the err...twisted nature of this example, if values are not
cached, such a modification would cause any k assignments and f(n) calls
to be re-evaluated.  If a user wants to evaluate f(n) using the
*current* value of k, he simply needs to place f(n) at the *end* of the
document, and *nothing* would be re-evaluated.

So, our little experiments at the end of our worksheets are always safe
from forcing a full re-evaluation, unless we edit/execute out of order,
in which case I *want* to be notified that things are in an inconsistent
state.

I think that it is *always impossible* to trigger a re-evaluation by
adding code strictly to the end of a worksheet.  But please come up with
a counter-example to this hypothesis.

I would even advocate an "experiment" tab, which would be effectively a
sub-document.  That is, when used it would copy the kernel's entire
state from the main document.  Therefore interactions which might cause
a full re-evaluation (such as adding two f(n) and then editing the first
one in the experimental tab) would not infect the main document.
However, the dependency tracking could easily tell the user that what is
now in the experimental tab is not consistent with the main document.  A
full re-eval would start by copying the main kernel state, rather than
re-evaluating the main worksheet.

Keeping a full variable state for each input line would reduce re-evals
even more, and obviate the need for an "experiment" tab, at the expense
of memory usage.  (again: toggleable user preference)  As Mma keeps In[]
and Out[] anyway, I don't think a full variable history could be any
worse in size than Out[].  You only need to know the variable state at
the end of each block, not each time a variable is modified.

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

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]