Re: RandomReal gets stuck
- To: mathgroup at smc.vnet.net
- Subject: [mg100427] Re: RandomReal gets stuck
- From: Bill Rowe <readnews at sbcglobal.net>
- Date: Wed, 3 Jun 2009 01:11:45 -0400 (EDT)
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.