Hi,
Sorry for my confusion, but I noticed (as a result of the discussion
here [1]) that np.rint and the fallback C function [2] seem to round
to even. But - my impression was that C rint, by default, rounds down
[3]. Is numpy rint not behaving the same way as the GNU C library
rint?
In [4]: np
On Fri, Jan 19, 2018 at 3:30 AM, Matthew Brett
wrote:
> Hi,
>
> Sorry for my confusion, but I noticed (as a result of the discussion
> here [1]) that np.rint and the fallback C function [2] seem to round
> to even. But - my impression was that C rint, by default, rounds down
> [3]. Is numpy ri
On Fri, Jan 19, 2018 at 6:41 AM, Charles R Harris wrote:
>
>
> On Fri, Jan 19, 2018 at 3:30 AM, Matthew Brett
> wrote:
>
>> Hi,
>>
>> Sorry for my confusion, but I noticed (as a result of the discussion
>> here [1]) that np.rint and the fallback C function [2] seem to round
>> to even. But - my
Hi Chuck,
Thanks for the replies, they are very helpful.
On Fri, Jan 19, 2018 at 1:51 PM, Charles R Harris
wrote:
>
>
> On Fri, Jan 19, 2018 at 6:41 AM, Charles R Harris
> wrote:
>>
>>
>>
>> On Fri, Jan 19, 2018 at 3:30 AM, Matthew Brett
>> wrote:
>>>
>>> Hi,
>>>
>>> Sorry for my confusion, bu
tl;dr: I think that our stream-compatibility policy is holding us back, and
I think we can come up with a way forward with a new policy that will allow
us to innovate without seriously compromising our reliability.
To recap, our current policy for numpy.random is that we guarantee that the
stream
I am confused . Shouldn't rint round to nearest integer.
http://en.cppreference.com/w/cpp/numeric/math/rint
Regards Mads
On Jan 19, 2018 15:50, "Matthew Brett" wrote:
> Hi Chuck,
>
> Thanks for the replies, they are very helpful.
>
> On Fri, Jan 19, 2018 at 1:51 PM, Charles R Harris
> wrote:
>
On Fri, Jan 19, 2018 at 11:56 PM, Mads Ipsen wrote:
>
> I am confused . Shouldn't rint round to nearest integer.
http://en.cppreference.com/w/cpp/numeric/math/rint
It does. Matthew was asking specifically about its behavior when it is
rounding numbers ending in .5, not the general case. Since tha
On Fri, Jan 19, 2018 at 7:48 AM, Matthew Brett
wrote:
> Hi Chuck,
>
> Thanks for the replies, they are very helpful.
>
> On Fri, Jan 19, 2018 at 1:51 PM, Charles R Harris
> wrote:
> >
> >
> > On Fri, Jan 19, 2018 at 6:41 AM, Charles R Harris
> > wrote:
> >>
> >>
> >>
> >> On Fri, Jan 19, 2018 a
Hi,
On Fri, Jan 19, 2018 at 3:24 PM, Charles R Harris
wrote:
>
>
> On Fri, Jan 19, 2018 at 7:48 AM, Matthew Brett
> wrote:
>>
>> Hi Chuck,
>>
>> Thanks for the replies, they are very helpful.
>>
>> On Fri, Jan 19, 2018 at 1:51 PM, Charles R Harris
>> wrote:
>> >
>> >
>> > On Fri, Jan 19, 2018 a
On Fri, Jan 19, 2018 at 8:24 AM, Charles R Harris wrote:
>
>
> On Fri, Jan 19, 2018 at 7:48 AM, Matthew Brett
> wrote:
>
>> Hi Chuck,
>>
>> Thanks for the replies, they are very helpful.
>>
>> On Fri, Jan 19, 2018 at 1:51 PM, Charles R Harris
>> wrote:
>> >
>> >
>> > On Fri, Jan 19, 2018 at 6:4
On Fri, Jan 19, 2018 at 8:27 AM, Matthew Brett
wrote:
> Hi,
>
> On Fri, Jan 19, 2018 at 3:24 PM, Charles R Harris
> wrote:
> >
> >
> > On Fri, Jan 19, 2018 at 7:48 AM, Matthew Brett
> > wrote:
> >>
> >> Hi Chuck,
> >>
> >> Thanks for the replies, they are very helpful.
> >>
> >> On Fri, Jan 19,
On Fri, Jan 19, 2018 at 8:45 AM, Charles R Harris wrote:
>
>
> On Fri, Jan 19, 2018 at 8:27 AM, Matthew Brett
> wrote:
>
>> Hi,
>>
>> On Fri, Jan 19, 2018 at 3:24 PM, Charles R Harris
>> wrote:
>> >
>> >
>> > On Fri, Jan 19, 2018 at 7:48 AM, Matthew Brett > >
>> > wrote:
>> >>
>> >> Hi Chuck,
>
On Fri, Jan 19, 2018 at 9:55 AM, Robert Kern wrote:
> tl;dr: I think that our stream-compatibility policy is holding us back,
> and I think we can come up with a way forward with a new policy that will
> allow us to innovate without seriously compromising our reliability.
>
> To recap, our curren
On Fri, Jan 19, 2018 at 6:57 AM Robert Kern wrote:
> As an alternative, we may also want to leave `np.random.RandomState`
> entirely fixed in place as deprecated legacy code that is never updated.
> This would allow current unit tests that depend on the stream-compatibility
> that we previously p
> Date: Fri, 19 Jan 2018 23:55:57 +0900
> From: Robert Kern
>
> tl;dr: I think that our stream-compatibility policy is holding us back, and
> I think we can come up with a way forward with a new policy that will allow
> us to innovate without seriously compromising our reliability.
>
> I propose t
On Sat, Jan 20, 2018 at 2:27 AM, wrote:
> I'm not sure I fully understand
> Is the proposal to drop stream-backward compatibility completely for the
future or just a one time change?
For all future.
> > No version-selection API would be required as you select the version by
installing the desir
On Sat, Jan 20, 2018 at 2:57 AM, Stephan Hoyer wrote:
>
> On Fri, Jan 19, 2018 at 6:57 AM Robert Kern wrote:
>>
>> As an alternative, we may also want to leave `np.random.RandomState`
entirely fixed in place as deprecated legacy code that is never updated.
This would allow current unit tests that
On Fri, Jan 19, 2018 at 6:55 AM, Robert Kern wrote:
[...]
> There seems to be a lot of pent-up motivation to improve on the random
> number generation, in particular the distributions, that has been blocked by
> our policy. I think we've lost a few potential first-time contributors that
> have run
18 matches
Mail list logo
