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