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>
- "dereference" variable