Re: [Numpy-discussion] random.uniform documentation bug?
On Tue, Feb 23, 2010 at 6:21 AM, Alan G Isaac ais...@american.edu wrote: This behavior does not match the current documentation. np.random.uniform(low=0.5,high=0.5) 0.5 np.random.uniform(low=0.5,high=0.4) 0.48796883601707464 I assume this behavior is intentional and it is Why do you assume that? DG the documentation that is in error (for the case when high=low)? fwiw, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
On Tue, Feb 23, 2010 at 08:21, Alan G Isaac ais...@american.edu wrote: This behavior does not match the current documentation. np.random.uniform(low=0.5,high=0.5) 0.5 np.random.uniform(low=0.5,high=0.4) 0.48796883601707464 I assume this behavior is intentional and it is the documentation that is in error (for the case when high=low)? Well, the documentation just doesn't really address high=low. In any case, the claim that the results are in [low, high) is wrong thanks to floating point arithmetic. It has exactly the same issues as the standard library's random.uniform() and should be updated to reflect that fact: random.uniform(a, b) Return a random floating point number N such that a = N = b for a = b and b = N = a for b a. The end-point value b may or may not be included in the range depending on floating-point rounding in the equation a + (b-a) * random(). We should address the high low case in the documentation because we're not going to bother raising an exception when high low. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
On Tue, Feb 23, 2010 at 10:29 AM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 08:21, Alan G Isaac ais...@american.edu wrote: This behavior does not match the current documentation. np.random.uniform(low=0.5,high=0.5) 0.5 np.random.uniform(low=0.5,high=0.4) 0.48796883601707464 I assume this behavior is intentional and it is the documentation that is in error (for the case when high=low)? Well, the documentation just doesn't really address high=low. In any case, the claim that the results are in [low, high) is wrong thanks to floating point arithmetic. It has exactly the same issues as the standard library's random.uniform() and should be updated to reflect that fact: random.uniform(a, b) Return a random floating point number N such that a = N = b for a = b and b = N = a for b a. The end-point value b may or may not be included in the range depending on floating-point rounding in the equation a + (b-a) * random(). We should address the high low case in the documentation because we're not going to bother raising an exception when high low. Well, an exception isn't the only option (e.g., it could return NaN), but does everyone agree (or at least not block) that this is acceptable behavior? IMO, if this function is going to allow high low, then the doc should _also_ be _quite_ clear that if this feature might mess up the user's program in some way, then the user will have to implement their own safeguard against such parameters being fed to the monster. ;-) DG -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
On Tue, Feb 23, 2010 at 13:05, David Goldsmith d.l.goldsm...@gmail.com wrote: On Tue, Feb 23, 2010 at 10:29 AM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 08:21, Alan G Isaac ais...@american.edu wrote: This behavior does not match the current documentation. np.random.uniform(low=0.5,high=0.5) 0.5 np.random.uniform(low=0.5,high=0.4) 0.48796883601707464 I assume this behavior is intentional and it is the documentation that is in error (for the case when high=low)? Well, the documentation just doesn't really address high=low. In any case, the claim that the results are in [low, high) is wrong thanks to floating point arithmetic. It has exactly the same issues as the standard library's random.uniform() and should be updated to reflect that fact: random.uniform(a, b) Return a random floating point number N such that a = N = b for a = b and b = N = a for b a. The end-point value b may or may not be included in the range depending on floating-point rounding in the equation a + (b-a) * random(). We should address the high low case in the documentation because we're not going to bother raising an exception when high low. Well, an exception isn't the only option (e.g., it could return NaN), shudder but does everyone agree (or at least not block) that this is acceptable behavior? It's a useful feature. Whenever there is a low/high pair of arguments, a user frequently has to write code like so: low, high = min(a, b), max(a, b) just to satisfy the argument spec of the function. This function does not really require knowing which is which for its implementation, so requiring them to be one way is simply arbitrariness for the sake of arbitrariness. IMO, if this function is going to allow high low, then the doc should _also_ be _quite_ clear that if this feature might mess up the user's program in some way, then the user will have to implement their own safeguard against such parameters being fed to the monster. ;-) So do it. But please, don't use frightening terminology like you are here. Just state the fact clearly and succinctly as in the random.uniform() docs. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
On Tue, Feb 23, 2010 at 11:25 AM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 13:05, David Goldsmith d.l.goldsm...@gmail.com wrote: On Tue, Feb 23, 2010 at 10:29 AM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 08:21, Alan G Isaac ais...@american.edu wrote: This behavior does not match the current documentation. np.random.uniform(low=0.5,high=0.5) 0.5 np.random.uniform(low=0.5,high=0.4) 0.48796883601707464 I assume this behavior is intentional and it is the documentation that is in error (for the case when high=low)? Well, the documentation just doesn't really address high=low. In any case, the claim that the results are in [low, high) is wrong thanks to floating point arithmetic. It has exactly the same issues as the standard library's random.uniform() and should be updated to reflect that fact: random.uniform(a, b) Return a random floating point number N such that a = N = b for a = b and b = N = a for b a. The end-point value b may or may not be included in the range depending on floating-point rounding in the equation a + (b-a) * random(). We should address the high low case in the documentation because we're not going to bother raising an exception when high low. Well, an exception isn't the only option (e.g., it could return NaN), shudder but does everyone agree (or at least not block) that this is acceptable behavior? It's a useful feature. Whenever there is a low/high pair of arguments, a user frequently has to write code like so: low, high = min(a, b), max(a, b) just to satisfy the argument spec of the function. This function does not really require knowing which is which for its implementation, so requiring them to be one way is simply arbitrariness for the sake of arbitrariness. OK. IMO, if this function is going to allow high low, then the doc should _also_ be _quite_ clear that if this feature might mess up the user's program in some way, then the user will have to implement their own safeguard against such parameters being fed to the monster. ;-) So do it. But please, don't use frightening terminology like you are here. Just state the fact clearly and succinctly as in the random.uniform() docs. Aw shucks, these docstrings are so dry. (Just kidding.) ;-) DG -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
Why not rewriting the definition of uniform() to: def uniform(start, stop, low = None, high = None): if low is not None: start = low if high is not None: stop = high [and here what matters] This makes no trouble when a user uses either non-keyword or keyword specification. The second pair of keywords is just for backward compatibility. As after a keyword there is no positional argument allowed, the only call mixing keywords and non-keywords would be uniform(low, high = high), and this is also maintained. Friedrich 2010/2/23 David Goldsmith d.l.goldsm...@gmail.com: On Tue, Feb 23, 2010 at 11:25 AM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 13:05, David Goldsmith d.l.goldsm...@gmail.com wrote: On Tue, Feb 23, 2010 at 10:29 AM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 08:21, Alan G Isaac ais...@american.edu wrote: This behavior does not match the current documentation. np.random.uniform(low=0.5,high=0.5) 0.5 np.random.uniform(low=0.5,high=0.4) 0.48796883601707464 I assume this behavior is intentional and it is the documentation that is in error (for the case when high=low)? Well, the documentation just doesn't really address high=low. In any case, the claim that the results are in [low, high) is wrong thanks to floating point arithmetic. It has exactly the same issues as the standard library's random.uniform() and should be updated to reflect that fact: random.uniform(a, b) Return a random floating point number N such that a = N = b for a = b and b = N = a for b a. The end-point value b may or may not be included in the range depending on floating-point rounding in the equation a + (b-a) * random(). We should address the high low case in the documentation because we're not going to bother raising an exception when high low. Well, an exception isn't the only option (e.g., it could return NaN), shudder but does everyone agree (or at least not block) that this is acceptable behavior? It's a useful feature. Whenever there is a low/high pair of arguments, a user frequently has to write code like so: low, high = min(a, b), max(a, b) just to satisfy the argument spec of the function. This function does not really require knowing which is which for its implementation, so requiring them to be one way is simply arbitrariness for the sake of arbitrariness. OK. IMO, if this function is going to allow high low, then the doc should _also_ be _quite_ clear that if this feature might mess up the user's program in some way, then the user will have to implement their own safeguard against such parameters being fed to the monster. ;-) So do it. But please, don't use frightening terminology like you are here. Just state the fact clearly and succinctly as in the random.uniform() docs. Aw shucks, these docstrings are so dry. (Just kidding.) ;-) DG ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
On Tue, Feb 23, 2010 at 14:04, Friedrich Romstedt friedrichromst...@gmail.com wrote: Why not rewriting the definition of uniform() to: def uniform(start, stop, low = None, high = None): if low is not None: start = low if high is not None: stop = high [and here what matters] This makes no trouble when a user uses either non-keyword or keyword specification. The second pair of keywords is just for backward compatibility. As after a keyword there is no positional argument allowed, the only call mixing keywords and non-keywords would be uniform(low, high = high), and this is also maintained. Except for someone calling uniform(low, high, size). In any case, why would you make this change? It doesn't seem to solve any problem or clear up any semantics. start and stop imply a stop start relationship, too, albeit not as strongly. If someone wants to pass in a high low, let them. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
Except for someone calling uniform(low, high, size). Ah, sorry, I didn't know about that. In that case, everything I wrote is superfluous and I apologise for a non-helping comment. But, one could incorporate SIZE simply in the calling convention. In any case, why would you make this change? It doesn't seem to solve any problem or clear up any semantics. start and stop imply a stop start relationship, too, albeit not as strongly. Hmm, I thought that start is where the thing starts, and stop where it stops, so it's in virtual time stop start, but it can travel downwards. I thought it would help making the semantics more clear. But I see it depends on interpretation. With low and high, my interpretation is on the contrary impossible. The ugly doubling was just intended for compatibility, resulting in a note for backward compatibility reasons, you can also pass ... or something like that. If someone wants to pass in a high low, let them. It's possible, of course. Friedrich ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
On Tue, Feb 23, 2010 at 14:26, Friedrich Romstedt friedrichromst...@gmail.com wrote: In any case, why would you make this change? It doesn't seem to solve any problem or clear up any semantics. start and stop imply a stop start relationship, too, albeit not as strongly. Hmm, I thought that start is where the thing starts, and stop where it stops, so it's in virtual time stop start, but it can travel downwards. I thought it would help making the semantics more clear. It helps a little, I agree, but not as much as simply changing the names to something neutral like (a, b) as in the standard library. The necessity for a backwards compatibility hack imposes additional costs to making any such change. I don't think those costs are warranted by the semantic confusion of allowing high low. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
2010/2/23 Robert Kern robert.k...@gmail.com: It helps a little, I agree, but not as much as simply changing the names to something neutral like (a, b) as in the standard library. The necessity for a backwards compatibility hack imposes additional costs to making any such change. I don't think those costs are warranted by the semantic confusion of allowing high low. I agree fully. The (a, b) thing is the most elegant. And I also agree that the overhead renders it nearly useless, when one focuses on speed. Sorry for making noise again with an unmature thought. It just came into my mind and looked so cute ... :-( Friedrich ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
On Tue, Feb 23, 2010 at 14:51, Friedrich Romstedt friedrichromst...@gmail.com wrote: 2010/2/23 Robert Kern robert.k...@gmail.com: It helps a little, I agree, but not as much as simply changing the names to something neutral like (a, b) as in the standard library. The necessity for a backwards compatibility hack imposes additional costs to making any such change. I don't think those costs are warranted by the semantic confusion of allowing high low. I agree fully. The (a, b) thing is the most elegant. And I also agree that the overhead renders it nearly useless, when one focuses on speed. Sorry for making noise again with an unmature thought. It just came into my mind and looked so cute ... :-( No worries! I'm not trying to discourage you from posting half-baked thoughts. They're often correct! -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
2010/2/23 Robert Kern robert.k...@gmail.com: No worries! I'm not trying to discourage you from posting half-baked thoughts. They're often correct! Thank you :-) *smiling and laughing* ! Friedrich P.S.: But my reply obviously does no longer belong to the mailing list ... ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
On Tue, Feb 23, 2010 at 1:02 PM, Friedrich Romstedt friedrichromst...@gmail.com wrote: 2010/2/23 Robert Kern robert.k...@gmail.com: No worries! I'm not trying to discourage you from posting half-baked thoughts. They're often correct! Thank you :-) *smiling and laughing* ! Friedrich P.S.: But my reply obviously does no longer belong to the mailing list ... For better or worse, institutional memory, be it baked, half-baked, or raw, is best preserved. :-) DG ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
Incidentally, I noted the following in the discussion, but since those don't get as much viewership (and since I'm about to edit the docstring anyway): presently, the Example in uniform's docstring generates a plot using matplotlib.pyplot - is generating a plot really consistent w/ the spirit of wanting our examples to pass automated testing? DG ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] random.uniform documentation bug?
OK, fixed in Wiki. ( OK to apply set to Yes) DG On Tue, Feb 23, 2010 at 10:29 AM, Robert Kern robert.k...@gmail.com wrote: On Tue, Feb 23, 2010 at 08:21, Alan G Isaac ais...@american.edu wrote: This behavior does not match the current documentation. np.random.uniform(low=0.5,high=0.5) 0.5 np.random.uniform(low=0.5,high=0.4) 0.48796883601707464 I assume this behavior is intentional and it is the documentation that is in error (for the case when high=low)? Well, the documentation just doesn't really address high=low. In any case, the claim that the results are in [low, high) is wrong thanks to floating point arithmetic. It has exactly the same issues as the standard library's random.uniform() and should be updated to reflect that fact: random.uniform(a, b) Return a random floating point number N such that a = N = b for a = b and b = N = a for b a. The end-point value b may or may not be included in the range depending on floating-point rounding in the equation a + (b-a) * random(). We should address the high low case in the documentation because we're not going to bother raising an exception when high low. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
