Re: Re: "dereference" variable

*To*: mathgroup at smc.vnet.net*Subject*: [mg82105] Re: [mg82071] Re: [mg82033] "dereference" variable*From*: DrMajorBob <drmajorbob at bigfoot.com>*Date*: Fri, 12 Oct 2007 02:56:04 -0400 (EDT)*References*: <200710100822.EAA26488@smc.vnet.net> <30346C40-5665-4B7C-B0FA-96E651F05229@jeol.com> <24156236.1192095978583.JavaMail.root@m35>*Reply-to*: drmajorbob at bigfoot.com

> I tried that, and it works OK. But I lose a lot of Mathematica's > knowledge of the properties of Sum, which I would rather not do. You can Replace mySum with Sum whenever you want, though: s=mySum[x,{k,1,20}] s/.mySum->Sum This is another way of Holding the original expression, in effect. Bobby On Wed, 10 Oct 2007 23:20:27 -0500, Todd Johnson <johnsong at ics.uci.edu> wrote: > >>> so that what L actually receives is a value like "s$123456". Q, on >>> the other hand, evaluates "s" entirely, and arrives at "20*k". You >>> may wonder, "but wait, that is what s evaluates to, why can't your >>> code deal with that?" The simplest answer is that sometimes >>> Mathematica seems to decide erroneously that the summation can be >>> turned into multiplication, >> >> It's not erroneous you need to follow the evaluation sequence, >> Mathematica does not operate the way languages like C or Java do, it >> uses a strict read eval loop, it reads an expression checks if there' s >> a rule that can be used to evaluate it and continues doing so until >> there is nothing left to evaluate. For that matter the idea of >> references and passing by value or reference does not map well. >> >>> which leaves me with dummy variables from summations lying around >>> unbound. >> >> What variables are unbound? I don't see any. > > > I'm sorry, I wasn't very clear. This was a very much stripped > down/faked-up version of the code which has these problems. This code > doesn't have any unbound variables because it's so simple. But sometimes > I'll write something like > > Sum[Sum[j,{j, 1, > someweird[nestedexpression[with,i,as,an,argument,somewhere]]}],{i,1,imax}] > > and get > > imax*Sum[j,{j, 1, > someweird[nestedexpression[with,i,as,an,argument,somewhere]]}] > > and now the "i" in the iterator for the inner loop doesn't have any > meaning. > > Although, to be honest, I haven't seen an example of that behavior in a > while, so I can't draw up an example that displays it. > >>> Also, this is a problem at other times, such as when there is an >>> appreciable difference between "x[[i]]-x[[i]]" and "0", because I >>> really mean "x[[i]]" to stand in for some vector of as-yet-unknown >>> length, so that it minus itself is a zero vector, which is different >>> from plain 0. >> >> Again you are fighting the evaluation sequence, if you don't want to >> evaluate x[[i]]-x[[i]] because you are going to define an evaluation >> rule for x later, you shouldn't evaluate that expression until the >> right time. > > > The goal of the bit of code I'm writing is to examine/modify/optimize > some code to be executed later, so it's not really an option to wait > until I have a value for x. > > >> s=mySum[x,{k,1,20}] >> >> L[mySum[x__]]:=Print["here"] > > I tried that, and it works OK. But I lose a lot of Mathematica's > knowledge of the properties of Sum, which I would rather not do. > >> >> Regards, >> > > Thanks for your help. It seems pretty clear that what I want to do can't > be done, and I will just have to work around that. > >> Ssezi > > todd. > > -- DrMajorBob at bigfoot.com

**References**:**"dereference" variable***From:*Todd Johnson <johnsong@ics.uci.edu>

**Re: JLink**

**Strange behaviour of Do in Compile**

**Re: "dereference" variable**

**Re: "dereference" variable**