[Numpy-discussion] making "low" optional in numpy.randint

[G Young]

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 <
jfoxrabinovitz at gmail.com> wrote:

> On Wed, Feb 17, 2016 at 1:37 PM,  <josef.pktd at gmail.com> wrote:
> >
> >
> > On Wed, Feb 17, 2016 at 10:01 AM, G Young <gfyoung17 at 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 at scipy.org
> >> https://mail.scipy.org/mailman/listinfo/numpy-discussion
> >>
> >
> >
> > _______________________________________________
> > NumPy-Discussion mailing list
> > NumPy-Discussion at scipy.org
> > https://mail.scipy.org/mailman/listinfo/numpy-discussion
> >
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20160217/bcdf4a4f/attachment.html>