rward (Robert Kern)
>2. Re: Using np.frombuffer and cffi.buffer on array of C structs
> (problem with struct member padding) (Joe)
>
>
> --
>
> Message: 1
> Date: Sat, 27 Jan 2018 09:28:54 +0900
> Fr
On Tue, Jan 30, 2018 at 5:39 AM, Pierre de Buyl <
pierre.deb...@chem.kuleuven.be> wrote:
>
> Hello,
>
> On Sat, Jan 27, 2018 at 09:28:54AM +0900, Robert Kern wrote:
> > On Sat, Jan 27, 2018 at 1:14 AM, Kevin Sheppard
> > wrote:
> > >
> > > In terms of what is needed, I think that the underlying PR
Hello,
On Sat, Jan 27, 2018 at 09:28:54AM +0900, Robert Kern wrote:
> On Sat, Jan 27, 2018 at 1:14 AM, Kevin Sheppard
> wrote:
> >
> > In terms of what is needed, I think that the underlying PRNG should
> be swappable. The will provide a simple mechanism to allow certain
> types of advancement w
On Sat, Jan 27, 2018 at 1:14 AM, Kevin Sheppard
wrote:
>
> I am a firm believer that the current situation is not sustainable.
There are a lot of improvements that can practically be incorporated.
While many of these are performance related, there are also improvements in
accuracy over some ranges
I am a firm believer that the current situation is not sustainable. There
are a lot of improvements that can practically be incorporated. While many
of these are performance related, there are also improvements in accuracy
over some ranges of parameters that cannot be incorporated. I also think
t
On Fri, Jan 19, 2018 at 6:13 PM Nathaniel Smith wrote:
> ...
> I agree that relaxing our policy would be better than the status quo.
> Before making any decisions, though, I'd like to make sure we
> understand the alternatives and their trade-offs. Specifically, I
> think the main alternative
On Sat, Jan 20, 2018 at 7:34 AM, Robert Kern wrote:
>
> 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.
To color this a little, while w
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
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 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
> 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 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
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
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
14 matches
Mail list logo
