Re: Re: Re: RandomReal gets stuck

*To*: mathgroup at smc.vnet.net*Subject*: [mg100460] Re: [mg100450] Re: [mg100427] Re: RandomReal gets stuck*From*: Andrzej Kozlowski <akoz at mimuw.edu.pl>*Date*: Thu, 4 Jun 2009 06:33:15 -0400 (EDT)*References*: <200906040733.DAA11950@smc.vnet.net>

On 4 Jun 2009, at 16:33, A. B. wrote: > >> From reading the documentation, it is not clear why this difference >> could > have consequences on subsequent computations. > Defining y[1]=10 simply creates a value rule for a DownValue for y. > In this > case y itself has no particular value. Setting x=5 gives an OwnValue > to x. > > Any thoughts from the experts on the safety of using the notation > y[i] for > "subscripted" variables ? > > A.B. > It's much safer than using Subscripted variables for "subscripted" variables. Andrzej Kozlowski > > > >> On 6/2/09 at 6:45 AM, szhorvat at gmail.com (Szabolcs) wrote: >> >>> On Jun 1, 2:11 pm, Bill Rowe <readnews at sbcglobal.net> wrote: >>>> >>>> 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. >> >>> This was perfectly good input. There is nothing wrong with it. It >>> asks the minimum of the sum of 31 variables (which of course does >>> not exist, but this doesn't mean that the question is mathematically >>> incorrect, or that the input is syntactically wrong). >> >> I disagree. The code asked for the minimum of 31 *functions* not >> 31 variables. Variables are not functions. >> >> While I agree it is often convenient to think of y[1] as either >> a subscripted variable or the first value of an array, it is >> neither. There is a clear difference in behavior when it comes >> to assignments. Assignments to symbols used as variables result >> in the symbol having an OwnValue not a DownValue. That is: >> >> In[1]:= x = 1 >> >> Out[1]= 1 >> >> In[2]:= OwnValues[x] >> >> Out[2]= {HoldPattern[x]:>1} >> >> In[3]:= DownValues[x] >> >> Out[3]= {} >> >> This is just opposite of what happens with assignments made to >> functions. That is: >> >> In[4]:= y[1] = 3 >> >> Out[4]= 3 >> >> In[5]:= OwnValues[y] >> >> Out[5]= {} >> >> In[6]:= DownValues[y] >> >> Out[6]= {HoldPattern[y(1)]:>3} >> >> There is a clear difference that will cause differences when >> these are used in other computations. Simply stated the syntax >> y[1] is not a variable and should only be used as a variable >> with a great deal of care and understanding. >> >>> However, the validity of this input has absolutely nothing to do >>> with the seriousness of this bug. This is the kind of bug that is >>> very hard to forgive because it's completely unexpected. >> >> You seem to be missing my point here. Invalid input simply is >> not guaranteed to have predictable results. Until the problem >> with the input is fixed, it isn't possible to say whether the >> result is a bug or not. >> >> In any case, the code used by the original poster did not >> include definitions of functions being used. And without those >> definitions, there was no way to verify the code he was using >> was valid. And that lack means there is no way to clearly know >> whether his result was due to a bug in Mathematica or his code. >> >> > >

**References**:**Re: Re: RandomReal gets stuck***From:*"A. B." <functionalcoatings@gmail.com>

**Re: Re: problem writing debugging utility function**

**Re: Replacing expressions with smaller atoms**

**Re: Re: RandomReal gets stuck**

**Re: RandomReal gets stuck**