RandomReal gets stuck
Bas Straatman
For a simulation of a stochastic process I am making use of RandomReal.
I noticed that at some point during the simulation the output of
RandomReal[] becomes fixed. For some reason, totally beyond my
comprehension, every time after I execute an optimization the
RandomReal[] generates the same series of random numbers:
In[217]:= optimalactivity
Out[217]= {24, 336/25, 616/25, 32/5, 28/5, 76/25, 4, 8, 8, 4/5, 0, 0, \
0, 0, 0, 4/5, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
0, 0, 0, 0, 0, 12, 28, 80, 0, 104/3, 0, 234/125, 0, 0, 0, 0, 4, 0, 0, \
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
In[218]:= RandomReal[]
Out[218]= 0.455719
In[219]:= RandomReal[]
Out[219]= 0.977826
In[220]:= RandomReal[]
Out[220]= 0.943215
In[221]:= RandomReal[]
Out[221]= 0.962216
In[222]:= RandomReal[]
Out[222]= 0.302348
In[223]:= optimalactivity
Out[223]= {24, 336/25, 616/25, 32/5, 28/5, 76/25, 4, 8, 8, 4/5, 0, 0, \
0, 0, 0, 4/5, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
0, 0, 0, 0, 0, 12, 28, 80, 0, 104/3, 0, 234/125, 0, 0, 0, 0, 4, 0, 0, \
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
In[224]:= RandomReal[]
Out[224]= 0.455719
In[225]:= RandomReal[]
Out[225]= 0.977826
In[226]:= RandomReal[]
Out[226]= 0.943215
In[227]:= RandomReal[]
Out[227]= 0.962216
In[228]:= RandomReal[]
Out[228]= 0.302348
optimalactivity simpy calculates an optimum allocation of resources:
optimalactivity := Table[y[i], {i, Length[inputmatrix]}] /. Maximize[
Plus @@ (Table[y[i], {i, Length[inputmatrix]}].(outputmatrix -
inputmatrix))[[consumables - 2]], CONDITIONS ,
Table[y[i], {i, Length[inputmatrix]}]][[2]]
There is no SeedRandom[] anywhere to be found.
Any ideas how this is possible? Thanks.
Bas Straatman
Bill Rowe
>For a simulation of a stochastic process I am making use of
>RandomReal. I noticed that at some point during the simulation the
>output of RandomReal[] becomes fixed. For some reason, totally
>beyond my comprehension, every time after I execute an optimization
>the RandomReal[] generates the same series of random numbers:
<snip>
>optimalactivity simpy calculates an optimum allocation of resources:
>optimalactivity := Table[y[i], {i, Length[inputmatrix]}] /. Maximize[
>Plus @@ (Table[y[i], {i, Length[inputmatrix]}].(outputmatrix -
>inputmatrix))[[consumables - 2]], CONDITIONS , Table[y[i], {i,
>Length[inputmatrix]}]][[2]]
>There is no SeedRandom[] anywhere to be found.
While it is true the code fragment above makes no call to
SeedRandom, that really doesn't mean much at all. This code
fragment calls several other things that are defined elsewhere
and makes no call to RandomReal. That is the problem has to be
at a lower level in the code you've written.
On my machine, there is no evidence RandomReal gets "stuck". For example,
In[1]:= Length@Union@Table[RandomReal[], {10^6}]
Out[1]= 1000000
In[2]:= $Version
Out[2]= 7.0 for Mac OS X x86 (64-bit) (February 19, 2009)
Note, it is more efficient to generate a million random values using
RandomReal[1, {10^6}]
I simply chose to use Table to call RandomReal a large number of
times since this is what you were doing.
Sjoerd C. de Vries
I can confirm this bug.
Executing an even simpler version, namely
Maximize[Plus @@ Table[y[i], {i, 31}], Table[y[i], {i, 31}]];
will also set the random generator to a fixed starting point. The
number 31 is crucial, as lower values do not appear to cause the bug,
while higher values do. Changing Plus to Times appears to prevent the
bug.
In[394]:= Table[
Maximize[Plus @@ Table[y[i], {i, 31}], Table[y[i], {i, 31}]];
RandomReal[],
{20}
]
During evaluation of In[394]:= Maximize::natt: The maximum is not
attained at any point satisfying the given constraints. >>
Out[394]= {0.455719, 0.455719, 0.455719, 0.455719, 0.455719, \
0.455719, 0.455719, 0.455719, 0.455719, 0.455719, 0.455719, 0.455719,
\
0.455719, 0.455719, 0.455719, 0.455719, 0.455719, 0.455719, 0.455719,
\
0.455719}
This is very nasty, as a lot of people critically depend on random
functions to be random. I would urge you to report this to wolfram
support.
Cheers -- Sjoerd
> optimalactivity := Table[y[i], {i, Length[inputmatrix]}] /. Maxi=
mize[
> Plus @@ (Table[y[i], {i, Length[inputmatrix]}].(outputmatrix =
Mark Fisher
wrote:
\
> > 0, 0, 0, 4/5, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
> > 0, 0, 0, 0, 0, 12, 28, 80, 0, 104/3, 0, 234/125, 0, 0, 0, 0, 4, 0, 0, \
> > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
>
> > In[218]:= RandomReal[]
>
> > Out[218]= 0.455719
>
> > In[219]:= RandomReal[]
>
> > Out[219]= 0.977826
>
> > In[220]:= RandomReal[]
>
> > Out[220]= 0.943215
>
> > In[221]:= RandomReal[]
>
> > Out[221]= 0.962216
>
> > In[222]:= RandomReal[]
>
> > Out[222]= 0.302348
>
> > In[223]:= optimalactivity
>
\
> > 0, 0, 0, 4/5, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
> > 0, 0, 0, 0, 0, 12, 28, 80, 0, 104/3, 0, 234/125, 0, 0, 0, 0, 4, 0, 0, \
> > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
>
> > In[224]:= RandomReal[]
>
> > Out[224]= 0.455719
>
> > In[225]:= RandomReal[]
>
> > Out[225]= 0.977826
>
> > In[226]:= RandomReal[]
>
> > Out[226]= 0.943215
>
> > In[227]:= RandomReal[]
>
> > Out[227]= 0.962216
>
> > In[228]:= RandomReal[]
>
> > Out[228]= 0.302348
>
> > optimalactivity simpy calculates an optimum allocation of resources:
>
xi=
> mize[
> > Plus @@ (Table[y[i], {i, Length[inputmatrix]}].(outputmatri=
x =
> -
> > inputmatrix))[[consumables - 2]], CONDITIONS ,
> > Table[y[i], {i, Length[inputmatrix]}]][[2]]
>
> > There is no SeedRandom[] anywhere to be found.
>
> > Any ideas how this is possible? Thanks.
>
> > Bas Straatman
>
>
Very disturbing. Dan, Rob, Darren: Any ideas as to what's going on and
how to avoid it until it's fixed (soon, I hope).
--Mark
Bill Rowe
Vries) wrote:
>I can confirm this bug.
>Executing an even simpler version, namely
>Maximize[Plus @@ Table[y[i], {i, 31}], Table[y[i], {i, 31}]];
>will also set the random generator to a fixed starting point. The
>number 31 is crucial, as lower values do not appear to cause the
>bug, while higher values do. Changing Plus to Times appears to
>prevent the bug.
>In[394]:= Table[
>Maximize[Plus @@ Table[y[i], {i, 31}], Table[y[i], {i, 31}]];
>RandomReal[], {20}
>]
When I execute the code above, I do get the same result as you
report. Clearly, there is a problem here somewhere. But it isn't
clear the issue is with RandomReal.
The code above uses Maximize in a non-sensical way, particularly
when the function y hasn't been defined. This usage asks
Mathematica to find the maximize the sum of n things with
respect to each of the n things. It appears there is an attempt
to use the notation y[n] to mean an array indexed by n rather
than a function of n. So, Maximize correctly generates error
messages. What is unexpected is poor input to Maximize appears
to cause a problem for RandomReal.
On my system, changing Plus to Times eliminates the effect on
RandomReal even though there is still a non-sensical input to
Maximize. Alternatively, defining y then executing the code does
In[5]:= y[n_] := n^2 - n
In[6]:= Table[
Maximize[Plus @@ Table[y[i], {i, 31}], Table[y[i], {i, 31}]];
RandomReal[], {20}]
During evaluation of In[6]:= Maximize::ivar: 0 is not a valid
variable. >>
During evaluation of In[6]:= Maximize::ivar: 0 is not a valid
variable. >>
During evaluation of In[6]:= Maximize::ivar: 0 is not a valid
variable. >>
During evaluation of In[6]:= General::stop: Further output of
Maximize::ivar will be suppressed during this calculation. >>
Out[6]= {0.877054,0.833103,0.703786,0.0482118,0.226066,0.230746,0.0738072=
,0.680963,0.53264,0.989333,0.418793,0.951114,0.963168,0.870439,0.926361,0.267113,0.195084,0.810066,0.875896,0.579076}
>This is very nasty, as a lot of people critically depend on random
>functions to be random. I would urge you to report this to wolfram
>support.
I agree many people including myself depend on the random
functions to be random. And I would also like Mathematica to
fail gracefully when given non-sensical input and provide useful
error messages. But I am never surprised when software does
something other than fail gracefully given non-sensical input or
provides less than useful error messages.
Entering
Table[
Maximize[Plus @@ Table[y[i], {i, 31}], Table[y[i], {i, 31}]];
RandomReal[],
{20}
]
into a new session and expecting useful output simply isn't a
reasonable expectation.
Note, this in no way says what the original poster was doing is
unreasonable or non-sensical. The rest of the information needed
to determine whether what the original poster was attempting is
sensible hasn't been provided. I would also note, that sending a
bug report to Wolfram without the additional information is
probably pointless.
Szabolcs
wrote:
> Hi Bas,
>
> I can confirm this bug.
>
> Executing an even simpler version, namely
>
> Maximize[Plus @@ Table[y[i], {i, 31}], Table[y[i], {i, 31}]];
>
> will also set the random generator to a fixed starting point. The
> number 31 is crucial, as lower values do not appear to cause the bug,
> while higher values do. Changing Plus to Times appears to prevent the
> bug.
>
> In[394]:= Table[
> Maximize[Plus @@ Table[y[i], {i, 31}], Table[y[i], {i, 31}]];
> RandomReal[],
> {20}
> ]
>
> During evaluation of In[394]:= Maximize::natt: The maximum is not
> attained at any point satisfying the given constraints. >>
>
> Out[394]= {0.455719, 0.455719, 0.455719, 0.455719, 0.455719, \
> 0.455719, 0.455719, 0.455719, 0.455719, 0.455719, 0.455719, 0.455719,
> \
> 0.455719, 0.455719, 0.455719, 0.455719, 0.455719, 0.455719, 0.455719,
> \
> 0.455719}
>
> This is very nasty, as a lot of people critically depend on random
> functions to be random. I would urge you to report this to wolfram
> support.
>
The problem is present both in version 6.0.3 and version 7.0.1.
Bas Straatman
I know the problem can't be found in the little piece of code that I
included in the first posting. For obvious reasons I didn't include all
code. But I don't know of any other way to reset the random number
generator than by making use of SeedRandom[] and nowhere in the notebook
or mathematica session I made use of that function. Therefore, I am
pretty sure that the problem is not in my code.
It does seem to be related to the use of Maximize. More in particular,
as Sjoerd de Vries noticed, it depends somehow on the number of
variables that Maximize has to deal with. Initially random reals in my
simulations appear to be random, but at some point, when the model grows
(I am simulating evolving artificial economies) the random number
generator starts to produce the same series of random numbers over and
over again.
It also doesn't matter whether or not Maximize is used non-sensical or
appropriately. Below I use variables y1, ...y32, not indexed by means of
square brackets, I even provide proper boundaries such that a solution
exist, and still the same issue with RandomReal turns up.
In[1]:= $Version
Out[1]= "7.0 for Microsoft Windows (32-bit) (November 10, 2008)"
In[2]:= Table[RandomReal[], {5}]
Out[2]= {0.289496, 0.40001, 0.634792, 0.389652, 0.528876}
In[3]:= size = 30
Out[3]= 30
In[4]:= Maximize[
Plus @@ Table[ToExpression["y" <> ToString[i]], {i, size}],
Map[# <= 10 &, Table[ToExpression["y" <> ToString[i]], {i, size}]],
Table[ToExpression["y" <> ToString[i]], {i, size}]]
Out[4]= {300, {y1 -> 10, y2 -> 10, y3 -> 10, y4 -> 10, y5 -> 10,
y6 -> 10, y7 -> 10, y8 -> 10, y9 -> 10, y10 -> 10, y11 -> 10,
y12 -> 10, y13 -> 10, y14 -> 10, y15 -> 10, y16 -> 10, y17 -> 10,
y18 -> 10, y19 -> 10, y20 -> 10, y21 -> 10, y22 -> 10, y23 -> 10,
y24 -> 10, y25 -> 10, y26 -> 10, y27 -> 10, y28 -> 10, y29 -> 10,
y30 -> 10}}
In[5]:= Table[RandomReal[], {5}]
Out[5]= {0.911008, 0.0662658, 0.193939, 0.302682, 0.159269}
In[6]:= Maximize[
Plus @@ Table[ToExpression["y" <> ToString[i]], {i, size}],
Map[# <= 10 &, Table[ToExpression["y" <> ToString[i]], {i, size}]],
Table[ToExpression["y" <> ToString[i]], {i, size}]] ;
Table[RandomReal[], {5}]
Out[7]= {0.121323, 0.296845, 0.0190161, 0.531837, 0.65849}
In[8]:= size = 31
Out[8]= 31
In[9]:= Maximize[
Plus @@ Table[ToExpression["y" <> ToString[i]], {i, size}],
Map[# <= 10 &, Table[ToExpression["y" <> ToString[i]], {i, size}]],
Table[ToExpression["y" <> ToString[i]], {i, size}]]
Out[9]= {310, {y1 -> 10, y2 -> 10, y3 -> 10, y4 -> 10, y5 -> 10,
y6 -> 10, y7 -> 10, y8 -> 10, y9 -> 10, y10 -> 10, y11 -> 10,
y12 -> 10, y13 -> 10, y14 -> 10, y15 -> 10, y16 -> 10, y17 -> 10,
y18 -> 10, y19 -> 10, y20 -> 10, y21 -> 10, y22 -> 10, y23 -> 10,
y24 -> 10, y25 -> 10, y26 -> 10, y27 -> 10, y28 -> 10, y29 -> 10,
y30 -> 10, y31 -> 10}}
In[10]:= Table[RandomReal[], {5}]
Out[10]= {0.455719, 0.977826, 0.943215, 0.962216, 0.302348}
In[11]:= Maximize[
Plus @@ Table[ToExpression["y" <> ToString[i]], {i, size}],
Map[# <= 10 &, Table[ToExpression["y" <> ToString[i]], {i, size}]],
Table[ToExpression["y" <> ToString[i]], {i, size}]] ;
Table[RandomReal[], {5}]
Out[12]= {0.455719, 0.977826, 0.943215, 0.962216, 0.302348}
In[13]:= size = 32
Out[13]= 32
In[14]:= Maximize[
Plus @@ Table[ToExpression["y" <> ToString[i]], {i, size}],
Map[# <= 10 &, Table[ToExpression["y" <> ToString[i]], {i, size}]],
Table[ToExpression["y" <> ToString[i]], {i, size}]]
Out[14]= {320, {y1 -> 10, y2 -> 10, y3 -> 10, y4 -> 10, y5 -> 10,
y6 -> 10, y7 -> 10, y8 -> 10, y9 -> 10, y10 -> 10, y11 -> 10,
y12 -> 10, y13 -> 10, y14 -> 10, y15 -> 10, y16 -> 10, y17 -> 10,
y18 -> 10, y19 -> 10, y20 -> 10, y21 -> 10, y22 -> 10, y23 -> 10,
y24 -> 10, y25 -> 10, y26 -> 10, y27 -> 10, y28 -> 10, y29 -> 10,
y30 -> 10, y31 -> 10, y32 -> 10}}
In[15]:= Table[RandomReal[], {5}]
Out[15]= {0.455719, 0.977826, 0.943215, 0.962216, 0.302348}
In[16]:= Maximize[
Plus @@ Table[ToExpression["y" <> ToString[i]], {i, size}],
Map[# <= 10 &, Table[ToExpression["y" <> ToString[i]], {i, size}]],
Table[ToExpression["y" <> ToString[i]], {i, size}]] ;
Table[RandomReal[], {5}]
Out[17]= {0.455719, 0.977826, 0.943215, 0.962216, 0.302348}
I received an email from from Daniel Lichtblau (Wolfram Research) that
it probably is a bug, I have sent him the above example and hope that it
gets sorted out quickly.
Bas
Sjoerd C. de Vries
> when the function y hasn't been defined. This usage asks
> Mathematica to find the maximize the sum of n things with
> respect to each of the n things. It appears there is an attempt
> to use the notation y[n] to mean an array indexed by n rather
> than a function of n. So, Maximize correctly generates error
> messages. What is unexpected is poor input to Maximize appears
> to cause a problem for RandomReal.
Bill,
I don't think you understood what I was trying to do. I merely
simplified Bas' code to something that had the same effects on random
number generation. The use of y[i] was taken from Bas' example. I
don't think he meant to index an array. You can use y[1], y[2] etc.
just as any other variable.
The error message in Maximize is not material to the problem. I ask
Mathematica to maximize an unbounded sum of variables. It's a
perfectly legal (though unsolvable) problem. That it responds with an
error message doesn't matter (I can -and have- come up with more
elaborate functions that have the same problem with random numbers but
don't cause Maximize to generate a warning). The problem is that
Maximize with 31 or more variables resets the random number generator.
In the mean time, Wolfram has confirmed this is indeed the case and it
will be fixed in a new realease.
Cheers -- Sjoerd
On Jun 1, 1:11 pm, Bill Rowe <readn...@sbcglobal.net> wrote:
> On 5/31/09 at 6:34 AM, sjoerd.c.devr...@gmail.com (Sjoerd C. de
> Out[6]= {0.877054,0.833103,0.703786,0.0482118,0.226066,0.230746,0.07380=
72=
> ,0.680963,0.53264,0.989333,0.418793,0.951114,0.963168,0.870439,0.926361,0=
Bas Straatman
to index a variable. Check out the array function:
In[1]:= Array[y, 3]
Out[1]= {y[1], y[2], y[3]}
In[2]:= Do[y[i] = 3 - i, {i, 3}]
In[3]:= ?y
Global`y
y[1]=2
y[2]=1
y[3]=0
In[4]:= Head[y]
Out[4]= Symbol
In[5]:= Head[y[1]]
Out[5]= Integer
Bas
Szabolcs
>
> I agree many people including myself depend on the random
> functions to be random. And I would also like Mathematica to
> fail gracefully when given non-sensical input and provide useful
> error messages. But I am never surprised when software does
> something other than fail gracefully given non-sensical input or
> provides less than useful error messages.
This was perfectly good input. There is nothing wrong with it. It
asks the minimum of the sum of 31 variables (which of course does not
exist, but this doesn't mean that the question is mathematically
incorrect, or that the input is syntactically wrong).
However, the validity of this input has absolutely nothing to do with
the seriousness of this bug. This is the kind of bug that is very
hard to forgive because it's completely unexpected.
A. B.
By the way, is the use of "indexed" variable names in the form x[i]
encouraged in Mathematica ? It doesn't make sense in mathematical notation
(as far as I am aware) and is not coherent with the use of brackets in
Mathematica.
A.B.
>> The code above uses Maximize in a non-sensical way, particularly
>> when the function y hasn't been defined. This usage asks
>> Mathematica to find the maximize the sum of n things with
>> respect to each of the n things. It appears there is an attempt
>> to use the notation y[n] to mean an array indexed by n rather
>> than a function of n. So, Maximize correctly generates error
>> messages. What is unexpected is poor input to Maximize appears
>> to cause a problem for RandomReal.
>
> Bill,
>
> I don't think you understood what I was trying to do. I merely
> simplified Bas' code to something that had the same effects on random
> number generation. The use of y[i] was taken from Bas' example. I
> don't think he meant to index an array. You can use y[1], y[2] etc.
> just as any other variable.
>
> The error message in Maximize is not material to the problem. I ask
> Mathematica to maximize an unbounded sum of variables. It's a
> perfectly legal (though unsolvable) problem. That it responds with an
> error message doesn't matter (I can -and have- come up with more
> elaborate functions that have the same problem with random numbers but
> don't cause Maximize to generate a warning). The problem is that
> Maximize with 31 or more variables resets the random number generator.
> In the mean time, Wolfram has confirmed this is indeed the case and it
> will be fixed in a new realease.
>
> Cheers -- Sjoerd
>
>
>
> On Jun 1, 1:11 pm, Bill Rowe <readn...@sbcglobal.net> wrote:
>> On 5/31/09 at 6:34 AM, sjoerd.c.devr...@gmail.com (Sjoerd C. de
>> Out[6]= {0.877054,0.833103,0.703786,0.0482118,0.226066,0.230746,0.07380=
> 72=
>> ,0.680963,0.53264,0.989333,0.418793,0.951114,0.963168,0.870439,0.926361,0=
> .267113,0.195084,0.810066,0.875896,0.579076}
>>
>>> This is very nasty, as a lot of people critically depend on random
>>> functions to be random. I would urge you to report this to wolfram
>>> support.
>>
>> I agree many people including myself depend on the random
>> functions to be random. And I would also like Mathematica to
>> fail gracefully when given non-sensical input and provide useful
>> error messages. But I am never surprised when software does
>> something other than fail gracefully given non-sensical input or
>> provides less than useful error messages.
>>
A. B.
Sorry, in the meantime I found the entry for this in the documentation which
explains precisely when and how this kind of notation can be useful.
A.B.
Bas Straatman
Random). That's what I am using now until a new release comes out.
Wolfram Research has confirmed that the new release will have this bug
fixed.
Bas
Bill Rowe
>On Jun 1, 2:11 pm, Bill Rowe <read...@sbcglobal.net> wrote:
>>
>>I agree many people including myself depend on the random functions
>>to be random. And I would also like Mathematica to fail gracefully
>>when given non-sensical input and provide useful error messages.
>>But I am never surprised when software does something other than
>>fail gracefully given non-sensical input or provides less than
>>useful error messages.
>This was perfectly good input. There is nothing wrong with it. It
>asks the minimum of the sum of 31 variables (which of course does
>not exist, but this doesn't mean that the question is mathematically
>incorrect, or that the input is syntactically wrong).
I disagree. The code asked for the minimum of 31 *functions* not
31 variables. Variables are not functions.
While I agree it is often convenient to think of y[1] as either
a subscripted variable or the first value of an array, it is
neither. There is a clear difference in behavior when it comes
to assignments. Assignments to symbols used as variables result
in the symbol having an OwnValue not a DownValue. That is:
In[1]:= x = 1
Out[1]= 1
In[2]:= OwnValues[x]
Out[2]= {HoldPattern[x]:>1}
In[3]:= DownValues[x]
Out[3]= {}
This is just opposite of what happens with assignments made to
functions. That is:
In[4]:= y[1] = 3
Out[4]= 3
In[5]:= OwnValues[y]
Out[5]= {}
In[6]:= DownValues[y]
Out[6]= {HoldPattern[y(1)]:>3}
There is a clear difference that will cause differences when
these are used in other computations. Simply stated the syntax
y[1] is not a variable and should only be used as a variable
with a great deal of care and understanding.
>However, the validity of this input has absolutely nothing to do
>with the seriousness of this bug. This is the kind of bug that is
>very hard to forgive because it's completely unexpected.
You seem to be missing my point here. Invalid input simply is
not guaranteed to have predictable results. Until the problem
with the input is fixed, it isn't possible to say whether the
result is a bug or not.
In any case, the code used by the original poster did not
include definitions of functions being used. And without those
definitions, there was no way to verify the code he was using
was valid. And that lack means there is no way to clearly know
whether his result was due to a bug in Mathematica or his code.
Bill Rowe
>By the way, Bill, there is nothing wrong with the use of square
>brackets to index a variable. Check out the array function:
>In[1]:= Array[y, 3]
>Out[1]= {y[1], y[2], y[3]}
>In[2]:= Do[y[i] = 3 - i, {i, 3}]
>In[3]:= ?y
>Global`y
>y[1]=2
>y[2]=1
>y[3]=0
>In[4]:= Head[y]
>Out[4]= Symbol
>In[5]:= Head[y[1]]
>Out[5]= Integer
My comments about y[1] were not that this is invalid syntax or
that it cannot be used in *some* cases like an indexed array or
subscripted variable. The point is it cannot be used as an
indexed array or subscripted variable in *all* cases. The syntax
y[1] is for a function named y evaluated at 1. The is not the
same as an indexed array nor the same as a subscripted variable.
In fact, the it does not even behave like an ordinary variable
in all ways. Specifically, for a ordinary symbol assignments
cause that symbol to have an OwnValue not a DownValue.
Assignments to a function cause the function to have a DownValue
not an OwnValue. These are different and the difference as
consequences in some evaluations.
If you have a clear understanding of the differences between
DownValues and OwnValues and know what you are doing, you
undoubtedly will get the result you want when treating y[1] as a
subscripted variable. On the other hand, if you lack a clear
understanding of the differences sooner or later you will
encounter unexpected issues (not bugs) when using y[1] as a
subscripted variable.
A. B.
>From reading the documentation, it is not clear why this difference could
have consequences on subsequent computations.
Defining y[1]=10 simply creates a value rule for a DownValue for y. In this
case y itself has no particular value. Setting x=5 gives an OwnValue to x.
Any thoughts from the experts on the safety of using the notation y[i] for
"subscripted" variables ?
A.B.
Andrzej Kozlowski
On 4 Jun 2009, at 16:33, A. B. wrote:
>
>> From reading the documentation, it is not clear why this difference
>> could
> have consequences on subsequent computations.
> Defining y[1]=10 simply creates a value rule for a DownValue for y.
> In this
> case y itself has no particular value. Setting x=5 gives an OwnValue
> to x.
>
> Any thoughts from the experts on the safety of using the notation
> y[i] for
> "subscripted" variables ?
>
> A.B.
>
It's much safer than using Subscripted variables for "subscripted"
variables.
Andrzej Kozlowski
Bas Straatman
the (old) mathematica book discusses the use of indexed objects.
Bas
Bill Rowe
>Apparently there is more to it than meets the eye, but section 2.5.5
>in the (old) mathematica book discusses the use of indexed objects.
In the fourth edition of the Mathematica Book, it is section
2.4.5 titled Making Definitions for Indexed Objects *briefly*
discusses using the syntax y[[0] etc as a "subscripted"
variable. Basically, this section shows an example where it is
more convenient to use this syntax over a list and has the
following statement:
You can think of the expression a[i] as being like an "indexed"
or "subscripted" variable.
None of what I've said really contradicts this. What I've done
is simply point out "being like" is not the same as "being".
That is, there are similarities between a subscripted variable
and the syntax a[i] but there is not an identity relationship.