[Numpy-discussion] Re: numarray: RandomArray2
jmiller at stsci.edu
Mon Aug 19 06:28:09 CDT 2002
Jochen Küpper wrote:
>On Sun, 18 Aug 2002 08:13:18 -0400 Todd Miller wrote:
>Todd> Jochen Küpper wrote:
>>>Looking at RandomArray2 I realized that the functions don't do any
>>>argument checking. Shouldn't uniform for example check at least
>>>| minimum != maximum
>>>or even make sure that maximum > minimum? (Although the result is
>>>probably "ok" if it isn't.) Something like
>>>| def uniform(minimum, maximum, shape=):
>>>| """Return array of random Floats in interval ]minimum, maximum[
>>>| with shape |shape|.
>>>| if maximum <= minimum:
>>>| raise ValueError
>>>| return minimum + (maximum-minimum)*random(shape)
>Todd> I am +0 on this. The parameter order emulates "range".
>Not exactly, currently:
>| >>> range(2, -4)
>| >>> ran.uniform(2, -4)
>That is, if max < min range returns an empty list, whereas uniform
>comes up with the same result as for (-4, 2) (well, "mirrored").
>Also note the "strange" docstring of range:
>| range([start,] stop[, step]) -> list of integers
>pointing straight toward its behavior.
>Todd> While it does look like it will compute the wrong answer if
>Todd> called incorrectly, that seems unlikely to me.
>Well, if max<min it "mirrors" the result inside the range. This is no
>problem as long as it is done "consistently". I don't have enough
>knowledge of RNG's to understand whether it is a problem (with respect
>to randomness) when calls with the right and wrong ordering of min and
>max are mixed.
>Thinking about the case min==max I must say it's a very wasted
>function call, but no actually big deal:
>| >>> import RandomArray2 as ran
>| >>> ran.uniform(1, 1)
>So well, maybe someone with insight into RNG's can comment on the,
>>>Moreover there are some inconsistencies between functions, i.e.:
>>>| def randint(minimum, maximum=None, shape=):
>>>| def random_integers(maximum, minimum=1, shape=):
>Todd> It appears to me that the parameter order of randint again
>Todd> emulates "range". The fact that random_integers is not
>Todd> consistent with randint seem OK to me because random_integers
>Todd> appears to have been written expressly to tailor the calling
>Todd> sequence of randint.
>Yes, initially I wondered why there are two functions at all. This
>explanation sounds like "we wanted some help in confusing the
I read it more like: someone wanted to make one particular user happy
by giving them the interface they asked for. Since writing
random_integers was easy, they did it even though it amounted to a small
duplication of effort and interface functionality. But, I'm just
>Todd> Because randint re-defines its parameters depending on whether 1
>Todd> or 2 range values are used, as does range, I don't think there
>Todd> is a completely consistent way to do this. Either we're "wrong"
>Todd> for the 1 parameter case or the 2 parameter case. The way it is
>Todd> specified now seems simplest to me, with "minimum" preceding
>Todd> "maximum", even though it is not strictly the correct name for
>Todd> the 1 parameter case.
>| uniform(limit1, limit2, shape=)
>and then range-like behaviour?
>But then, what do we return on
>| uniform(2, -4)
Perhaps my intuition about "range" was incorrect, or we're taking the
analogy too far. It seems to me that randint is returning random
numbers between two limits, and the order of the limits is irrelevant.
randint(2,-4) is identical to randint(-4,2). As you have pointed out,
this is distinctly different than range. At this point, I'm still
unconvinced that the world would be made a better place either by
raising an exception or by changing the semantics to return an "empty
array". That small change seems just as likely to upset some user as to
make another happy.
Todd Miller jmiller at stsci.edu
STSCI / SSG
More information about the Numpy-discussion