Re: Re: RandomReal gets stuck

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

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. > > 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: Re: RandomReal gets stuck**

**Psychrometric chart**

**Re: Re: RandomReal gets stuck**

**Re: Re: RandomReal gets stuck**