2015-05-29 14:06 GMT-07:00 Antony Lee antony@berkeley.edu:
A proof-of-concept implementation, still missing tests, is tracked as
#5911. It includes the patch proposed in #5158 as an example of how to
include an improved version of random.choice.
Tests are in now (whether we should
A proof-of-concept implementation, still missing tests, is tracked as
#5911. It includes the patch proposed in #5158 as an example of how to
include an improved version of random.choice.
Tests are in now (whether we should bundle in pickles of old versions to
make sure they are still
On 24 May 2015 at 22:30, Sturla Molden sturla.mol...@gmail.com wrote:
Personally I think we should only make guarantees about the data types,
array shapes, and things like that, but not about the values. Those who
need a particular version of NumPy for exact reproducibility should
install the
On Sun, May 24, 2015 at 2:41 PM, Alan G Isaac alan.is...@gmail.com wrote:
I echo Ralf's question.
For those who need replicability, the proposed upgrade path seems quite
radical.
It's not radical, and my question was already answered. Nothing changes if
you are doing:
On May 24, 2015 2:03 AM, Ralf Gommers ralf.gomm...@gmail.com wrote:
On Sun, May 24, 2015 at 10:22 AM, Antony Lee antony@berkeley.edu
wrote:
Hi,
As mentioned in
#1450: Patch with Ziggurat method for Normal distribution
#5158: ENH: More efficient algorithm for unweighted random choice
On 5/24/2015 8:47 AM, Ralf Gommers wrote:
Values only change if you leave out the call to seed()
OK, but this claim seems to conflict with the following language:
the global RandomState object should use the latest implementation of the
methods.
I take it that this is what Nathan meant by
I
On Sun, May 24, 2015 at 10:22 AM, Antony Lee antony@berkeley.edu
wrote:
Hi,
As mentioned in
#1450: Patch with Ziggurat method for Normal distribution
#5158: ENH: More efficient algorithm for unweighted random choice without
replacement
#5299: using `random.choice` to sample integers
On Sun, May 24, 2015 at 11:30 AM, Nathaniel Smith n...@pobox.com wrote:
So with this proposal, an unseeded RandomState uses the latest version -
therefore the global functions, which start out unseeded, start out using
the latest version. If you call .seed() on an existing RandomState object
I echo Ralf's question.
For those who need replicability, the proposed upgrade path seems quite radical.
Also, I would prefer to have the new functionality introduced beside the
existing
implementation of RandomState, with an announcement that RandomState
will change in the next major numpy
On Sun, May 24, 2015 at 9:08 AM, Alan G Isaac alan.is...@gmail.com wrote:
On 5/24/2015 8:47 AM, Ralf Gommers wrote:
Values only change if you leave out the call to seed()
OK, but this claim seems to conflict with the following language:
the global RandomState object should use the latest
On Sun, May 24, 2015 at 1:49 PM, Nathaniel Smith n...@pobox.com wrote:
On May 24, 2015 8:43 AM, josef.p...@gmail.com wrote:
Reminder: we are bottom or inline posting
Can we stop hassling people about this? Inline replies are a great tool to
have in your toolkit for complicated technical
On 24/05/15 17:13, Anne Archibald wrote:
Do we want a deprecation-like approach, so that eventually people who
want replicability will specify versions, and everyone else gets bug
fixes and improvements? This would presumably take several major
versions, but it might avoid people getting
On Sun, May 24, 2015 at 7:56 PM, Sturla Molden sturla.mol...@gmail.com
wrote:
On 24/05/15 20:04, Nathaniel Smith wrote:
I'm not sure what you're envisioning as needing a deprecation cycle? The
neat thing about random is that we already have a way for users to say
that they want
Do we want a deprecation-like approach, so that eventually people who want
replicability will specify versions, and everyone else gets bug fixes and
improvements? This would presumably take several major versions, but it
might avoid people getting unintentionally trapped on this version.
On Sun, May 24, 2015 at 7:46 PM, Sturla Molden sturla.mol...@gmail.com
wrote:
On 24/05/15 17:13, Anne Archibald wrote:
Do we want a deprecation-like approach, so that eventually people who
want replicability will specify versions, and everyone else gets bug
fixes and improvements? This
On Sun, May 24, 2015 at 11:13 AM, Anne Archibald archib...@astron.nl
wrote:
Do we want a deprecation-like approach, so that eventually people who want
replicability will specify versions, and everyone else gets bug fixes and
improvements? This would presumably take several major versions, but
On May 24, 2015 8:43 AM, josef.p...@gmail.com wrote:
Reminder: we are bottom or inline posting
Can we stop hassling people about this? Inline replies are a great tool to
have in your toolkit for complicated technical discussions, but I feel like
our weird insistence on them has turned into a
On May 24, 2015 8:15 AM, Anne Archibald archib...@astron.nl wrote:
Do we want a deprecation-like approach, so that eventually people who
want replicability will specify versions, and everyone else gets bug fixes
and improvements? This would presumably take several major versions, but it
might
On 24/05/15 20:04, Nathaniel Smith wrote:
I'm not sure what you're envisioning as needing a deprecation cycle? The
neat thing about random is that we already have a way for users to say
that they want replicability -- the use of an explicit seed --
No, this is not sufficient for random
Thanks to Nathaniel who has indeed clarified my intent, i.e. the global
RandomState should use the latest implementation, unless explicitly
seeded. More generally, the `RandomState` constructor is just a thin
wrapper around `seed` with the same signature, so one can swap the version
of the global
2015-05-24 13:30 GMT-07:00 Sturla Molden sturla.mol...@gmail.com:
On 24/05/15 10:22, Antony Lee wrote:
Comments, and help for writing tests (in particular to make sure
backwards compatibility is maintained) are welcome.
I have one comment, and that is what makes random numbers so special?
On May 24, 2015 11:04 AM, josef.p...@gmail.com wrote:
On Sun, May 24, 2015 at 1:49 PM, Nathaniel Smith n...@pobox.com wrote:
On May 24, 2015 8:43 AM, josef.p...@gmail.com wrote:
Reminder: we are bottom or inline posting
Can we stop hassling people about this? Inline replies are a great
On 24/05/15 10:22, Antony Lee wrote:
Comments, and help for writing tests (in particular to make sure
backwards compatibility is maintained) are welcome.
I have one comment, and that is what makes random numbers so special?
This applies to the rest of NumPy too, fixing a bug can sometimes
On Sun, May 24, 2015 at 5:09 PM, Antony Lee antony@berkeley.edu wrote:
2015-05-24 13:30 GMT-07:00 Sturla Molden sturla.mol...@gmail.com:
On 24/05/15 10:22, Antony Lee wrote:
Comments, and help for writing tests (in particular to make sure
backwards compatibility is maintained) are
Hi,
As mentioned in
#1450: Patch with Ziggurat method for Normal distribution
#5158: ENH: More efficient algorithm for unweighted random choice without
replacement
#5299: using `random.choice` to sample integers in a large range
#5851: Bug in np.random.dirichlet for small alpha parameters
some
25 matches
Mail list logo
