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

josef.pktd at gmail.com josef.pktd at gmail.com
Wed Feb 17 14:20:16 EST 2016


On Wed, Feb 17, 2016 at 2:09 PM, G Young <gfyoung17 at gmail.com> wrote:

> 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.
>


One problem is that if there is only one positional argument, then I can
still figure out that it might have different meanings.
If there are two keywords, then I would assume standard python argument
interpretation applies.

If I want to save on typing, then I think it should be for a more
"standard" case. (I also never sample all real numbers, at least not
uniformly.)

Josef



>
> 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
>>
>
>
> _______________________________________________
> 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/506f7c3b/attachment.html>


More information about the NumPy-Discussion mailing list