MathGroup Archive 2009

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Re: RandomReal gets stuck

  • To: mathgroup at
  • Subject: [mg100450] Re: [mg100427] Re: RandomReal gets stuck
  • From: "A. B." <functionalcoatings at>
  • 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 ?


> On 6/2/09 at 6:45 AM, szhorvat at (Szabolcs) wrote:
>> On Jun 1, 2:11 pm, Bill Rowe <readnews at> 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.

  • Prev by Date: Re: Tube in ParametricPlot3D with too many details
  • Next by Date: Documentation
  • Previous by thread: Re: Re: RandomReal gets stuck
  • Next by thread: Re: Re: Re: RandomReal gets stuck