Re: Compile. Not again

*To*: mathgroup at smc.vnet.net*Subject*: [mg56482] Re: [mg56470] Compile. Not again*From*: "Wolf, Hartmut" <Hartmut.Wolf at t-systems.com>*Date*: Tue, 26 Apr 2005 21:52:37 -0400 (EDT)*Sender*: owner-wri-mathgroup at wolfram.com

>-----Original Message----- >From: Maxim [mailto:ab_def at prontomail.com] To: mathgroup at smc.vnet.net >Sent: Tuesday, April 26, 2005 7:34 AM >Subject: [mg56482] [mg56470] Compile. Not again > >Here's what I get in version 5.1.0: > >In[1]:= f = Compile[{}, Module[{L = {0}}, L[[1]]++; L]] > >In[2]:= a = f[] >Out[2]= {1} > >In[3]:= b = f[] >Out[3]= {2} > >In[4]:= Table[f[], {3}] > >Out[4]= {{5}, {5}, {5}} > >In[5]:= {a, b} >Out[5]= {{5}, {5}} > >Each subsequent call to f uses the modified value of L. >This also affects Table and all the objects involved >in assignments such as x = f[] (but not >x = f[][[1]]), including DownValues[Out]. The problem >might be related to deciding whether a and b point to >the same shared object. > >Maxim Rytin >m.r at inbox.ru > > Maxim, compare this to In[1]:= L = {0}; In[2]:= f0[] := (L[[1]]++; L) In[3]:= (f0[]; a0 = Unevaluated[L]) Out[3]= {1} In[4]:= (f0[]; b0 = Unevaluated[L]) Out[4]= {2} In[5]:= Identity /@ Table[(f0[]; Unevaluated@Unevaluated[L]), {3}] Out[5]= {{5}, {5}, {5}} In[6]:= {a0, b0} Out[6]= {{5}, {5}} (There are yet other ways to simulate this.) So I might follow you that the OwnValues of a and b "point to the same object" (which is thought to be a constant, but isn't). This reminds me of old days of Fortran, where Compilers dealt constants as references, whith the effect that you could turn 5 e.g. to 7, by a function call. Table in your example is innocent, as this produces a list of the same references. We might have been warned off, however, by those meager words of Help: "Compiled code does not handle numerical precision and local variables in the same way as ordinary Mathematica code." -- Hartmut Wolf