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
>
>
>