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

[Joseph Fox-Rabinovitz]

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
>