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: Re: Re: RandomReal gets stuck