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 whether ,---- | 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) | -2.2346744537353516 `---- 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(...) | 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) | 1.0 `----
So well, maybe someone with insight into RNG's can comment on the, mirroring issue?
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.
Hmm,
v.s.
Yes, initially I wondered why there are two functions at all. This explanation sounds like "we wanted some help in confusing the users" :))
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 speculating.
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.
What's about ,---- | 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.
Your-even-more-confused-ly's, Jochen
Todd