Re: RandomReal gets stuck

*To*: mathgroup at smc.vnet.net*Subject*: [mg100489] Re: RandomReal gets stuck*From*: Bas Straatman <bastraat at ucalgary.ca>*Date*: Fri, 5 Jun 2009 03:04:29 -0400 (EDT)*Organization*: The University of Calgary*References*: <h050gq$a76$1@smc.vnet.net>

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. Bas A. B. wrote: > 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: difference between HeavisidePi and UnitBox**

**Re: Debugger, um, tutorial on it??**

**Re: Re: Re: RandomReal gets stuck**

**Re: RandomReal gets stuck**