Re: Re: RandomReal gets stuck

*To*: mathgroup at smc.vnet.net*Subject*: [mg100450] Re: [mg100427] Re: RandomReal gets stuck*From*: "A. B." <functionalcoatings at gmail.com>*Date*: Thu, 4 Jun 2009 03:33:42 -0400 (EDT)

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

**Follow-Ups**:**Re: Re: Re: RandomReal gets stuck***From:*Andrzej Kozlowski <akoz@mimuw.edu.pl>

**Re: Tube in ParametricPlot3D with too many details**

**Documentation**

**Re: Re: RandomReal gets stuck**

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