Re: Re: RandomReal gets stuck

*To*: mathgroup at smc.vnet.net*Subject*: [mg100410] Re: [mg100380] Re: RandomReal gets stuck*From*: "A. B." <functionalcoatings at gmail.com>*Date*: Wed, 3 Jun 2009 01:08:37 -0400 (EDT)

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... at sbcglobal.net> wrote: >> On 5/31/09 at 6:34 AM, sjoerd.c.devr... at gmail.com (Sjoerd C. de >> >> 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.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. >> >> 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. > >

**Re: Sidebar Tools**

**Re: Re: RandomReal gets stuck**

**Re: RandomReal gets stuck**

**Re: Re: RandomReal gets stuck**