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