Re: Warsaw Univ. course, was Re: Work on Basic
- To: mathgroup at smc.vnet.net
- Subject: [mg131019] Re: Warsaw Univ. course, was Re: Work on Basic
- From: Leonid Shifrin <lshifr at gmail.com>
- Date: Tue, 4 Jun 2013 01:59:03 -0400 (EDT)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- Delivered-to: l-mathgroup@wolfram.com
- Delivered-to: mathgroup-outx@smc.vnet.net
- Delivered-to: mathgroup-newsendx@smc.vnet.net
- References: <kmngb2$3rv$1@smc.vnet.net>
On Tue, Jun 4, 2013 at 12:45 AM, Richard Fateman <fateman at eecs.berkeley.edu>wrote: > On 6/3/2013 9:25 AM, Leonid Shifrin wrote: > > <long message> > > Thanks for what I consider a most agreeable contribution. > I was not aware of your material on stackexchange, which seems > to be rather nice. > Thanks, I do appreciate your opinion. > > > You are right that my example regarding mutable Lists in Mathematica > was incorrect. Actually on two grounds. The syntax was not right and > I did not mean to say that Lists in Mathematica are not mutable, since > they certainly are. > > Just that Lists have the uncomfortable property that if you access one > element, > all the others are re-evaluated. Here is an example, which I think is free > of > mis-used syntax... > > ( q=Table[f[i],{i,1,3}]; > f[n_]:=(Print[n];g[n])) > > q[[2]] > > evaluates to display > 1 > 2 > 3 > g[2] > > Changing q by, for example, q[[2]]=hello > does not re-evaluate the elements. > However, referring to in again as q[[2]] does this: > 1 > 3 > hello > Yes, this is indeed what happens. Arguably this is a correct behavior (for Mathematica), because Mathematica can not tell in advance that q will not evaluate to something else. For example, we could have q assigned to some other symbol, and that symbol to hold the list. In general, this is because Part does not hold its arguments. Given that Part works on general expressions, I don't find this inconsistent. If you don't want this behavior, one way out is to not store the values in a list, but rather store them in some head which holds their elements, such as Hold: In[5]:= q1 = Map[f, Hold @@ Range[3]] Out[5]= Hold[f[1], f[2], f[3]] In this case, we get In[6]:= q1[[2]] During evaluation of In[6]:= 2 Out[6]= g[2] Which seems to be the behavior you expected. One could use HoldComplete in place of Hold, which would arguably be even better since that would have prevented any non-trivial evaluation of q1 whasoever (including e.g. search for UpValues, not prevented by Hold). Regards, Leonid > > Thanks for pointing out the original error. > RJF > > >