My point is that you are proposing to make the overall API have
counter-intuitive behavior for the sake of adding a new feature. It is
worth a little bit of overhead to have two functions that behave
exactly as expected. Josef's footnote is a good example of how people
will feel about having to figure out (not to mention remember) the
different use cases. I think it is better to keep the current API and
just add a "bounded_randint" function for which an input of `None`
always means "limit of that bound, no exceptions".
-Joe
On Wed, Feb 17, 2016 at 2:09 PM, G Young <gfyoun...@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.
>
> 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
>
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
