Re: [Axiom-developer] Consistency (was Lazy Evaluation)

[William Sit]

"Page, Bill" wrote:

> Why don't we name the *new* Axiom user interface ScratchPad?

"Intelligent ScratchPad"? (to steal from your TM and comments)

  [snipped]

> Another approach that is perhaps more popular among computer
> programmers than it is among mathematicians is a kind of iterative
> approach. In this way of working one strives to always maintain
> one's creation in a consistent state. Programs are dynamic things
> that have complex and sometimes apparently unpredictable behaviors.
> In order to place some bounds on the amount of complexity that
> we have to deal with, we often write programs in small iterative
> steps. First a very simple version of the program is written that
> does some basic things - makes certain limited calculations - but
> does them right and consistently. Next we begin to make small
> iterative improvements, testing each improvement in an attempt to
> ensure that we have not "broken" anything by our changes.
> 
> I think that as more and better computer tools become available
> for mathematics, more mathematics may actually be done in this
> way.

One should not depend on "intelligent tools" to guide one's behavior. The
approach you mentioned above is already the practice of the day for me. Surely
each small piece of code or ideas for proof developed should be tested to a
consistent state before moving on. If some prefers these intelligent tools, fine
for them.  (I keep thinking of MS Word, and you may be right: more documents are
done the MS way.)
 
> [snipped]
> 
> > Why should I need consistency during the development? If
> > I am only working on some single subroutine, why shouldn't
> > I be able to test this in isolation?
> 
> To my mind these are two very different things. We need
> consistency during development in order to help manage the
> complexity which otherwise could very easily overwhelm our
> limited human abilities.

Ok, I will say that there are pauses in the development process when it is
important to check consistency before going on. What I meant was I do not need
to have consistency all the time and so I do not re-evaluation (or lazy one) all
the time.

[snipped]

> I agree that the new ScratchPad user interface should be able
> to support this kind of use.

Axiom already allows isolated tests if one starts a new frame. But Mathematica
and Maple do not. There are advantages and disadvantages to both. Some tests
cannot be totally isolated or need a simulated environment that is more
difficult to create than to just test them within the real main development.
 
> > If I keep track of dependencies with SetDelayed, there is
> > no need to worry about the eventual consistency. Even if I
> > can place code in  a linear space order, why can't I prefer
> > just a linear logical order? All I need is consistency of the
> > final code, which if it works, is automatic.
> 
> "which if it works, is automatic" ... that is the common
> presupposition of many less experienced computer programmers
> and software development companies with whom I have worked.
> They are often very reluctant to become involved in system
> testing and business case scenarios because they usually feel
> like this a waste of time since they have already shown with
> there unit tests that everything "should" (implying that it
> "will") work. But in every case that I know of, these people
> have been wrong. There is a whole computer science literature
> on this subject.

True. I should add, if it does not work, it is not the "final code".
In such case, how would LRE help me identify the "bugs"? In fact, I had just
recently written some code that helps me prove a mathematical result and my
first two or three versions are consistent, but wrong (because I overlooked some
cases)! Consistency simply say that the results you see are what the code
computes. There is no implication that the results reflect a correct solution to
the original problem.

> > For developers, it is the revision cycle that is time
> > consuming. I would like to have all the freedom available.
> 
> Reducing the revision cycle time is exactly what lazy
> re-evaluation is all about. I don't think that it needs
> to restrict your freedom in any way.
> 
Especially if I do not use it! 

Don't take this seriously; LRE has its role to reduce cycle time, as long as I
do not have to check the automatically recomputed results, which I almost ALWAYS
have to do in large spreadsheets --- not because the recomputations are wrong,
for Excel follows all the dependencies correctly, giving me always a consistent
spreadsheet, but because of MY mistakes --- to get to what I want eventually. My
point is, if one forgets to change some lines when one modifies another, even if
the state of the system is consistent, the answers may still be wrong. Sometimes
LRE will make you see the mistake faster, but more often, it won't tell you
where the logical mistakes are and it is still better if you can keep the
*logical state* in your head and make ALL the changes to a correct *logicial
state* before applying a recomputation. I would say that if recomputation (even
for LRE) takes a long time, I save time by not using it than using it if I
cannot keep the logical states clearly in my head.

William