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