52 views

Skip to first unread message

May 29, 2009, 9:00:14 PM5/29/09

to

Hi,

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

May 31, 2009, 6:30:57 AM5/31/09

to

On 5/29/09 at 9:00 PM, bast...@ucalgary.ca (Bas Straatman) wrote:

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

May 31, 2009, 6:33:47 AM5/31/09

to

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.

Cheers -- Sjoerd

> optimalactivity := Table[y[i], {i, Length[inputmatrix]}] /. Maxi=

mize[

> Plus @@ (Table[y[i], {i, Length[inputmatrix]}].(outputmatrix =

Jun 1, 2009, 7:04:23 AM6/1/09

to

On May 31, 6:33 am, "Sjoerd C. de Vries" <sjoerd.c.devr...@gmail.com>

wrote:> > 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]}] /. Ma=

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

>

>

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

Jun 1, 2009, 7:11:36 AM6/1/09

to

On 5/31/09 at 6:34 AM, sjoerd.c...@gmail.com (Sjoerd C. de

Vries) wrote:

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.

Jun 2, 2009, 6:37:46 AM6/2/09

to

On May 31, 1:33 pm, "Sjoerd C. de Vries" <sjoerd.c.devr...@gmail.com>

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.

>

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.

Jun 2, 2009, 6:40:26 AM6/2/09

to

Hi,

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

Jun 2, 2009, 6:41:09 AM6/2/09

to

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

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

Jun 2, 2009, 6:41:31 AM6/2/09

to

By the way, Bill, there is nothing wrong with the use of square brackets

to index a variable. Check out the array function:

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

Jun 2, 2009, 6:42:24 AM6/2/09

to

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.

>

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

Jun 3, 2009, 1:08:31 AM6/3/09

to

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.

>>

Jun 3, 2009, 1:08:42 AM6/3/09

to

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.

Jun 3, 2009, 1:11:24 AM6/3/09

to

Not in version 5.2, (it doesn't have RandomReal but it has the old

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.

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

Jun 3, 2009, 1:11:35 AM6/3/09

to

On 6/2/09 at 6:45 AM, szho...@gmail.com (Szabolcs) wrote:

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

Jun 3, 2009, 1:11:46 AM6/3/09

to

On 6/2/09 at 6:44 AM, bast...@ucalgary.ca (Bas Straatman) wrote:

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

Jun 5, 2009, 4:05:16 PM6/5/09

to

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

Jun 5, 2009, 4:07:39 PM6/5/09

to

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

Jun 5, 2009, 4:13:41 PM6/5/09

to

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.

the (old) mathematica book discusses the use of indexed objects.

Bas

Jun 6, 2009, 6:25:34 AM6/6/09

to

On 6/5/09 at 3:04 AM, bast...@ucalgary.ca (Bas Straatman) wrote:

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

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu