Re: evaluation-- one or many levels, your thoughts?
- To: mathgroup at smc.vnet.net
- Subject: [mg116994] Re: evaluation-- one or many levels, your thoughts?
- From: Noqsi <noqsiaerospace at gmail.com>
- Date: Mon, 7 Mar 2011 05:46:41 -0500 (EST)
- References: <ikq8gs$7vl$1@smc.vnet.net>
On Mar 4, 1:39 am, Richard Fateman <fate... at cs.berkeley.edu> wrote: > How often do you require the behavior that an expression > is evaluated until it stops changing, rather than evaluated > "once"? > > Difference in behavior.. > > once > x1=x2 > x2=x3 > > x1 evaluates to x2 > > "infinite" evaluation until stops changing.. > > x1 evaluates to x3. > > Note that with "once" evaluation, > x=x+1 sets x to "x+1" And, of course you can have that in Mathematica: expr/.x->x+1 Replace[] is a simple "evaluate once" construct. It's not a complex heuristic "try to figure out what I mean to do" construct, as you seem to want it to be in other threads. > > not "recursion depth exceeded". > > You may not have a clear idea of the answer to this question, since > conventionally Mathematica evaluates "as far as possible", and > you may not, therefore, have an idea of whether your programs > would still work under the "once" model. > I invite you to think about this, and whether another model > might work for you. I think that the evaluate once model is > less onerous for the implementor, and might speed up your > computing. Given the "once" model, one can easily write > "evaluate until no change". I think that for my purposes, invoking FixedPoint[] willy-nilly all over the place would be a burden, and would make expressions much harder to read. > The reverse emulation is > much harder, as far as I can tell. The complexity of > non-evaluation in Mathematica includes, among other operators, > Hold, Holdform, Defer, HoldAll, HoldFirst, HoldRest, Evaluate, > Unevaluated, ReleaseHold, HoldComplete, HoldPattern, HoldAllComplete, > SequenceHold, Update, NHoldAll, NHoldFirst, NHoldRest, With, Extract.. I've been using Mathematica for over 20 years, and I've never needed the majority of those. Understanding Set[] versus SetDelayed[], Condition[], and Replace[] cover 99% of the cases where evaluation needs to be controlled. And to me, they seemed very natural from the beginning, and still do. Remember that Mathematica is not fundamentally a "programming language" based on functions and procedures. It is a term rewriting system for evaluating mathematical expressions. Now, of course, that can *emulate* functions, and with a little extra help, procedures too. But it can also do things unanticipated by the lambda calculus: x_[whoCalled] ^:= x While for pure programming, term rewriting isn't the most natural foundation, it is very natural for manipulating mathematical expressions, I think. But the user must commit to actually using the paradigm, and not fighting it (this is true, of course, for *any* tool). I think you just like to fight. I'd rather get real work done. -jpd