Yes, you are correct in explaining my intentions. However, as I also mentioned in the PR discussion, I did not quite understand how your wrapper idea would make things any more comprehensive at the cost of additional overhead and complexity. What do you mean by making the functions "consistent" (i.e. outline the behavior *exactly* depending on the inputs)? As I've explained before, and I will state it again, the different behavior for the high=None and low != None case is due to backwards compatibility.
On Wed, Feb 17, 2016 at 6:52 PM, Joseph Fox-Rabinovitz < jfoxrabinov...@gmail.com> wrote: > On Wed, Feb 17, 2016 at 1:37 PM, <josef.p...@gmail.com> wrote: > > > > > > On Wed, Feb 17, 2016 at 10:01 AM, G Young <gfyoun...@gmail.com> wrote: > >> > >> Hello all, > >> > >> I have a PR open here that makes "low" an optional parameter in > >> numpy.randint and introduces new behavior into the API as follows: > >> > >> 1) `low == None` and `high == None` > >> > >> Numbers are generated over the range `[lowbnd, highbnd)`, where `lowbnd > = > >> np.iinfo(dtype).min`, and `highbnd = np.iinfo(dtype).max`, where > `dtype` is > >> the provided integral type. > >> > >> 2) `low != None` and `high == None` > >> > >> If `low >= 0`, numbers are <b>still</b> generated over the range `[0, > >> low)`, but if `low` < 0, numbers are generated over the range `[low, > >> highbnd)`, where `highbnd` is defined as above. > >> > >> 3) `low == None` and `high != None` > >> > >> Numbers are generated over the range `[lowbnd, high)`, where `lowbnd` is > >> defined as above. > > > > > > My impression (*) is that this will be confusing, and uses a default > that I > > never ever needed. > > > > Maybe a better way would be to use low=-np.inf and high=np.inf where inf > > would be interpreted as the smallest and largest representable number. > And > > leave the defaults unchanged. > > > > (*) I didn't try to understand how it works for various cases. > > > > Josef > > > > As I mentioned on the PR discussion, the thing that bothers me is the > inconsistency between the new and the old functionality, specifically > in #2. If high is, the behavior is completely different depending on > the value of `low`. Using `np.inf` instead of `None` may fix that, > although I think that the author's idea was to avoid having to type > the bounds in the `None`/`+/-np.inf` cases. I think that a better > option is to have a separate wrapper to `randint` that implements this > behavior in a consistent manner and leaves the current function > consistent as well. > > -Joe > > > > > > > >> > >> > >> The primary motivation was the second case, as it is more convenient to > >> specify a 'dtype' by itself when generating such numbers in a similar > vein > >> to numpy.empty, except with initialized values. > >> > >> Looking forward to your feedback! > >> > >> Greg > >> > >> _______________________________________________ > >> NumPy-Discussion mailing list > >> NumPy-Discussion@scipy.org > >> https://mail.scipy.org/mailman/listinfo/numpy-discussion > >> > > > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion@scipy.org > > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
