[MRG + 1] Set a random random_state at init to ensure deterministic randomness when random_state is `None` #7935

raghavrv · 2016-11-24T15:55:02Z

This is a better fix for #6726 as opposed to my previous #7660

Ensures deterministic randomness across multiple calls to split even when random_state is not set...

This replicates the behaviour of cross-validators in pre 0.18...

In master (0.18.1)

>>> from sklearn.model_selection import KFold

# Splits are different for multiple split calls when random_state is not set
>>> kf = KFold(n_splits=2, shuffle=True, random_state=None)
>>> for _ in range(2):
...     print(list(kf.split([1,] * 4)))
[(array([2, 3]), array([0, 1])), (array([0, 1]), array([2, 3]))]
[(array([1, 2]), array([0, 3])), (array([0, 3]), array([1, 2]))]

In this branch, splits are different for multiple initializations of cross-validators but same across multiple split calls for the same initialization.

>>> from sklearn.model_selection import KFold

# Splits are same for same initialization in successive split calls.
>>> kf = KFold(n_splits=2, shuffle=True, random_state=None)
>>> for _ in range(2):
...     print(list(kf.split([1,] * 4)))
[(array([2, 3]), array([0, 1])), (array([0, 1]), array([2, 3]))]
[(array([2, 3]), array([0, 1])), (array([0, 1]), array([2, 3]))]

# Splits are different for different initializations of cross-validators.
>>> for _ in range(2):
...     print(list(KFold(n_splits=2, shuffle=True, random_state=None).split([1,] * 4)))
[(array([0, 2]), array([1, 3])), (array([1, 3]), array([0, 2]))]
[(array([0, 3]), array([1, 2])), (array([1, 2]), array([0, 3]))]

Ping @GaelVaroquaux @jnothman @amueller

(Sorry for the tongue twisting PR title :p)

jnothman · 2016-11-24T21:39:22Z

Sorry about this.

raghavrv · 2016-11-24T23:45:34Z

No problem at all! :)

TomDLT · 2016-11-25T10:51:52Z

sklearn/model_selection/_split.py

+            # are random for each initialization of splitter but consistent
+            # across multiple calls for the same initialization.
+            self._random_state = check_random_state(
+                random_state).randint(99999999)


np.iinfo(np.int32).max instead of 99999999?
same below

you forgot this one

Ahh sorry. Done :)

TomDLT · 2016-11-25T10:52:46Z

sklearn/model_selection/tests/test_split.py

        for data in zip((X, X2), (y, y2)):
+            # For the same initialilzation, splits should be same across


initialilzation

TomDLT · 2016-11-25T10:53:59Z

sklearn/model_selection/tests/test_split.py

+            # multiple split calls, even when random_state is not set.
+            np.testing.assert_equal(list(cvs[0].split(*data)),
+                                    list(cvs[0].split(*data)))
+


Add # For different initialisations, splits should not be same when random_state is not set.

raghavrv · 2016-11-28T11:48:07Z

Have addressed your comments @TomDLT... Thx :)

raghavrv · 2016-11-28T12:23:33Z

@GaelVaroquaux Would you have some time for this one?

amueller

You also need to undo all the list-casting that is already in master, right? Also, I think I'm +.5 for not introducing a private attribute and using random_state instead directly.

amueller · 2016-11-28T20:48:15Z

sklearn/model_selection/_split.py

@@ -284,7 +284,16 @@ def __init__(self, n_splits, shuffle, random_state):

        self.n_splits = n_splits
        self.shuffle = shuffle
+        # For repr


What do you mean by this comment? You don't like an explicit random state in the __repr__? Because it's surprising for the user? It would make reproducing easier and not introduce a private variable that is dependent on a global state....

This means that doing cv.random_state = 10 doesn't do anything, though, even though it changes the __repr__.

On the other hand, having a number pop up here if it wasn't specified might be surprising for users that expect this to work like an Estimator object. Which it does not...

I thought about not having this but assumed it would be cleaner to reproduce the input that the user gave in repr instead of random. But your legitimate reasons justify the removal of this... I'll do and push in a while... Thnx

amueller · 2016-11-28T20:50:47Z

sklearn/model_selection/_split.py

@@ -560,9 +569,9 @@ def __init__(self, n_splits=3, shuffle=False, random_state=None):

    def _make_test_folds(self, X, y=None, groups=None):
        if self.shuffle:
-            rng = check_random_state(self.random_state)
+            rng = check_random_state(self._random_state)


this if still bothers me.

I thought about not having this but assumed it would be cleaner to reproduce the input that the user gave in repr instead of random. But your legitimate reasons justify the removal of this... I'll do and push in a while... Thnx

amueller · 2016-11-28T20:54:28Z

sklearn/model_selection/tests/test_split.py

            try:
-                np.testing.assert_equal(list(cv.split(*data)),
-                                        list(cv.split(*data)))
+                np.testing.assert_equal(list(cvs[1].split(*data)),


why don't you do assert_false(list(...) == list(...))?

That doesnt compare nested list of ndarrays...

assert_false(all([(x == y).all() for x, y in zip(cvs[1].split(*data), cv[2].split(*data))]))

hm... maybe not much better than the current one? It took me several reads to understand the error message you provide.

As @amueller pointed out I had a similar implementation of numpy.testing.assert_not_equal in #7946. I'd suggest we add that as a assert helper in sklearn/utils/testing.py.

@amueller I don't think your solution is future proof because you are in an edge case of array comparison when comparing arrays containing numpy arrays. Example:

import numpy as np arr = np.array([np.array([1, 2]), np.array([1, 2, 3])]) arr = arr # Returns: array([True, True], dtype=bool) # with warning: DeprecationWarning: numpy equal will not check object identity in the future. # The error trying to get the boolean value of the comparison result will be raised. arr1 = np.array([np.array([1, 2]), np.array([1, 2, 3])]) arr == arr1 # Returns: False # with warning: DeprecationWarning: elementwise == comparison failed; this will raise an error in the future.

Basically the first case kind of works because it falls-back to comparing identity of the inner arrays when element comparison does not return a scalar. The second case returns False because inner arrays are not identical.
More details at numpy/numpy#8323 (comment).

I was going by the current numpy implementation, which I guess you found a bug in?

raghavrv · 2016-11-28T21:08:00Z

Thanks for the review. The undoing of list casting is done at #7941 which would benefit from a review!

amueller · 2016-11-28T21:14:09Z

@raghavrv how are these two separate PRs? The undoing of list casting can only be done once the change in this PR is merged, right?

amueller · 2016-11-28T21:14:50Z

also, we're doing 0.18.2 for this? Sorry I was offline over the weekend but that's news to me.

jnothman · 2016-11-28T22:30:25Z

sklearn/model_selection/_split.py

+            # are random for each initialization of splitter but consistent
+            # across multiple calls for the same initialization.
+            self._random_state = check_random_state(
+                random_state).randint(np.iinfo(np.int32).max)


Gaël had instead suggested the use of get_state. Apart from the ability to represent many more than 2**32 possible states, it is faster to set the state than to seed a new RandomState.

I'm okay with this though.

Doing check_random_state(self.random_state).get_state() in all cases will ensure similar behaviour regardless of the form of the parameter.

Sorry could you elaborate a bit more? Get state gets me a tuple of the RandomState(...) object which represents it's state... Do you mean we store this at random_state? (That garbles the repr...)

What do you mean by "garble"? Show a RandomState object? That's fine, isn't it?

jnothman · 2016-11-28T22:30:27Z

sklearn/model_selection/_split.py

+            self._random_state = check_random_state(
+                random_state).randint(np.iinfo(np.int32).max)
+        else:
+            self._random_state = random_state


This will not produce the same splits each time if this is a RandomState instance.

good catch...

Wait I thought about this and did a copy I think... Or maybe I had it in my mind but didn't do anything... Anyway this needs a test... Thx!

raghavrv · 2016-11-28T22:34:49Z

@raghavrv how are these two separate PRs? The undoing of list casting can only be done once the change in this PR is merged, right?

Not exactly as we need to support one time iterables (at least for the time being) in grid search, I ensured the order of iteration while populating jobs for parallel is such that the splits are generated once and used for all parameters...

amueller · 2016-11-28T22:55:32Z

@raghavrv that seems to be true for some of the materializations but not all, which means that we could to that but then would have another PR to fix the remaining one. If we accept this PR, there is no need to change the loops, right?

raghavrv · 2016-11-28T23:02:50Z

seems to be true for some

All except learning_curve which was like that pre-0.18.

If we accept this PR, there is no need to change the loops, right?

But what about one time iterables? Do we still support them?

also, we're doing 0.18.2 for this? Sorry I was offline over the weekend but that's news to me.

I'm afraid that I'm gonna suggest yes, for like @GaelVaroquaux pointed out it really consumes a lot of memory especially if your data and/or splits are pretty large...

raghavrv · 2016-11-28T23:04:26Z

I'm sorry these approaches didn't cross my mind back then :/

amueller · 2016-11-28T23:05:14Z

Hm ok, for one-time iterables, I guess we do need to change the order. Did we support them in 0.17?
And I don't think this is worth a minor release. Can you come up with a scenario using scikit-learn built-in functions in which this will actually fix a memory issue?

raghavrv · 2016-11-28T23:10:29Z

No currently in 0.18.1, even for a normal cv splitter, the list gets materialized and hence consumes memory. I'll post a snippet comparing the memory tomorrow... But something like GridSearchCV(est, ..., cv=StratifiedShuffledSplit(n_splits=100))).fit(X, y) where X is ~ 1M samples would quickly give you an idea...

jnothman · 2016-11-28T23:15:24Z

From my perspective, anything without split() has to be materialised as a list.

…

On 29 November 2016 at 10:10, Raghav RV ***@***.***> wrote: No currently in 0.18.1, even for a normal cv splitter, the list gets materialized and hence consumes memory. I'll post a snipped comparing the memory tomorrow... But something like GridSearchCV(est, ..., cv=StratifiedShuffledSplit(n_splits=100)).split(X, y) where X is ~ 1M samples would quickly give you an idea... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7935 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEz6_ow61gbvsKDCRpuNubjo87CyVNrks5rC19mgaJpZM4K7ykQ> .

amueller · 2016-11-28T23:23:06Z

No currently in 0.18.1, even for a normal cv splitter, the list gets materialized and hence consumes memory. I'll post a snipped comparing the memory tomorrow... But something like GridSearchCV(est, ..., cv=StratifiedShuffledSplit(n_splits=100)).split(X, y) where X is ~ 1M samples would quickly give you an idea...

I guess if n_splits >> n_features this could run you into trouble.

I'm not sure I want to push out another hotfix for something we are not entirely sure about. The stronger contract is certainly better, but the back and forth with the behavior is also confusing. And for people doing repeated CV - which is relatively common - the new behavior could give pretty wrong results.

raghavrv · 2016-11-28T23:25:48Z

From my perspective, anything without split() has to be materialised as a list

Ah sorry I meant a fit not a split there. Have edited accordingly...

amueller · 2016-12-02T15:09:00Z

Hm... do we want KFold to be deterministic if random_state is a random state object?

raghavrv · 2016-12-02T15:11:49Z

I thought that we wanted the splits to be consistent for multiple split calls? Joel's comment

amueller · 2016-12-02T15:12:23Z

@raghavrv indeed, but that's not what your code currently implements, right? Have you tested that?

amueller · 2016-12-02T15:12:59Z

oh you changed it 4 minutes ago lol. I agree with your newest version, I was looking at the previous version and wanted to suggest exactly the fix you made (I think, haven't reviewed).

raghavrv · 2016-12-02T16:05:39Z

lol. I was skeptical when I got a review as soon as I pushed ;P

amueller

looks good apart from nitpicks.

amueller · 2016-12-03T00:01:25Z

sklearn/model_selection/_split.py

@@ -378,11 +378,11 @@ class KFold(_BaseKFold):
    >>> from sklearn.model_selection import KFold
    >>> X = np.array([[1, 2], [3, 4], [1, 2], [3, 4]])
    >>> y = np.array([1, 2, 3, 4])
-    >>> kf = KFold(n_splits=2)
+    >>> kf = KFold(n_splits=2, random_state=0)


why? There is no shuffle

The repr displays a random random_state that fails the test... So I explicitly set one...

amueller · 2016-12-03T00:01:46Z

sklearn/model_selection/_split.py

@@ -543,11 +543,11 @@ class StratifiedKFold(_BaseKFold):
    >>> from sklearn.model_selection import StratifiedKFold
    >>> X = np.array([[1, 2], [3, 4], [1, 2], [3, 4]])
    >>> y = np.array([0, 0, 1, 1])
-    >>> skf = StratifiedKFold(n_splits=2)
+    >>> skf = StratifiedKFold(n_splits=2, random_state=0)


no shuffle?

I don't like this. What we could do is instantiate the RandomState object only if shuffle=True? That would break if someone assigned cv.shuffle = True but that seems like an odd thing to do.

This is just confusing to users as is.

Which is why I wanted to preserve the user-set random state by preserving it in the original random_state variable. You suggested that it would be clear to the user to display the explicitly set random_state and hence the current setup...

I don't understand how your comment relates to my comment. You said the tests failed. You could have fixed that with a ....
If we want the repr to be nicer if shuffle is not set, we could not change it then.
I don't think we should change the repr in other cases and hide information from the user.

Okay so we want repr to preserve the user set random state or the default of None if shuffle is False, correct? In other cases set an explicit random_state if None and display the explicitly set random_state in repr... For the tests use ellipsis to suppress the test error. Sounds good?

amueller · 2016-12-03T00:02:54Z

sklearn/model_selection/_split.py

@@ -284,7 +284,14 @@ def __init__(self, n_splits, shuffle, random_state):

        self.n_splits = n_splits
        self.shuffle = shuffle
-        self.random_state = random_state
+        if not isinstance(random_state, (np.integer, numbers.Integral)):


Would you mind changing the order of the if instead of negating?

amueller · 2016-12-03T00:03:30Z

sklearn/model_selection/_split.py

@@ -922,7 +926,14 @@ def __init__(self, n_splits=10, test_size=0.1, train_size=None,
        self.n_splits = n_splits
        self.test_size = test_size
        self.train_size = train_size
-        self.random_state = random_state
+        if not isinstance(random_state, (np.integer, numbers.Integral)):


again, maybe change the order?

amueller · 2016-12-03T00:03:39Z

sklearn/model_selection/tests/test_split.py

@@ -147,17 +147,17 @@ def test_cross_validator_with_default_params():
    groups = np.array([1, 2, 3, 4])
    loo = LeaveOneOut()
    lpo = LeavePOut(p)
-    kf = KFold(n_splits)
-    skf = StratifiedKFold(n_splits)
+    kf = KFold(n_splits, random_state=0)


why? There's no shuffle

Same comment as above (repr)

amueller · 2016-12-03T00:05:14Z

sklearn/model_selection/tests/test_split.py


-    for cv in (kf, skf):
+    for cv in (kf, skf, kf2, skf2):


maybe add a comment saying "check that calling split twice yields the same results"

amueller · 2016-12-03T00:16:04Z

sklearn/model_selection/tests/test_split.py

        for data in zip((X, X2), (y, y2)):
+            # For the same initialization, splits should be same across
+            # multiple split calls, even when random_state is not set.
+            np.testing.assert_equal(list(cvs[0].split(*data)),


we only need one cross-validation object for that. Why is that not in the loop above?

amueller · 2016-12-03T00:16:43Z

sklearn/model_selection/tests/test_split.py

            try:
-                np.testing.assert_equal(list(cv.split(*data)),
-                                        list(cv.split(*data)))
+                np.testing.assert_equal(list(cvs[1].split(*data)),


why do we need three objects?

1st object is used to test if multiple calls to split produce same result if random_state is not set...

2nd and 3rd object are used to test if they produce different result if random_state is not set... (To ensure that by implicitly setting random_state we are not making it any less random for splits from separate initializations.) Though I could reuse 1st. I'd prefer having it this way to ensure that the previous test's split call on the 1st object does not affect the next test...

why not do the first one in the loop above? that makes much more sense to me.

raghavrv · 2016-12-05T15:14:27Z

Have addressed / clarified your comments. Could I have your +1?

raghavrv · 2016-12-06T16:11:46Z

@amueller @jnothman Could you see if the latest changes look okay?

amueller · 2016-12-06T18:13:16Z

sklearn/model_selection/tests/test_split.py

            try:
-                np.testing.assert_equal(list(cv.split(*data)),
-                                        list(cv.split(*data)))
+                np.testing.assert_equal(list(cv1.split(*data)),


I still think this is an ugly pattern but whatever... Is this the only place where we use this? Otherwise we might want to put this into utils?

Maybe for another PR? There are quite a few places (even outside model_selection) using np.testing.assert_*equal...

Sure. Though I was referring to the try: else: construct.

amueller · 2016-12-06T18:13:30Z

LGTM

jnothman · 2016-12-07T03:25:40Z

Before I review this again, I think we still need to determine whether the current approach is broken enough to justify this kind of backwards-incompatible change. With #7941 we're no longer materialising the list of CV indices, so we no longer have the memory issue. The problem is then that it may be surprising but documented behaviour that multiple calls to split will return different partitions if random_state does not make it deterministic. Is that bad enough to justify breaking compatibility between 0.18 and 0.19?

amueller · 2016-12-07T16:23:09Z

Hm... we introduced this behavior in 0.18 and now we're going back to where we were in 0.17, right? We didn't really intentionally change that in 0.18 and one could argue that this is a bug-fix to restore the old behavior.
On the other hand I guess changing twice is worse than changing once.

I'm kind of torn on this. Actually the behavior in current master is consistent with how estimators behave on fit.

jnothman · 2016-12-07T20:54:30Z

We had a different interface in 0.17. We had sufficient information at __init__ to determine the entire partition statically. Here we only have that information when split is called.

…

On 8 December 2016 at 03:23, Andreas Mueller ***@***.***> wrote: Hm... we introduced this behavior in 0.18 and now we're going back to where we were in 0.17, right? We didn't really intentionally change that in 0.18 and one could argue that this is a bug-fix to restore the old behavior. On the other hand I guess changing twice is worse than changing once. I'm kind of torn on this. Actually the behavior in current master is consistent with how estimators behave on fit. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7935 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEz67Q3UFPegXsEqxFVbxSKsuoqw4Ynks5rFt1ugaJpZM4K7ykQ> .

jnothman · 2016-12-07T20:55:17Z

You might make the analogy that current behaviour considers split like fit; proposed behaviour here considers split like transform.

…

On 8 December 2016 at 07:54, Joel Nothman ***@***.***> wrote: We had a different interface in 0.17. We had sufficient information at __init__ to determine the entire partition statically. Here we only have that information when split is called. On 8 December 2016 at 03:23, Andreas Mueller ***@***.***> wrote: > Hm... we introduced this behavior in 0.18 and now we're going back to > where we were in 0.17, right? We didn't really intentionally change that in > 0.18 and one could argue that this is a bug-fix to restore the old behavior. > On the other hand I guess changing twice is worse than changing once. > > I'm kind of torn on this. Actually the behavior in current master is > consistent with how estimators behave on fit. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#7935 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAEz67Q3UFPegXsEqxFVbxSKsuoqw4Ynks5rFt1ugaJpZM4K7ykQ> > . >

raghavrv · 2016-12-12T11:00:07Z

So shall I leave this open for further discussions or can we close this a won't fix? With #7941, the more serious underlying issue (of grid search not evaluating on consistent splits for different param) is fixed. This is just a syntactic nice to have to ensure compatibility with cross_validation but adds complexity I guess...

The implications are that with model_selection, the interface is different. It is now similar to fit and hence you are expected to explicitly set an integer random_state if you want shuffling for multiple split calls to be consistent... Using None or numpy's random state obj will not produce consistent splits...

Is there a direct unpleasant practical consequence of not having this PR?

Could I request a final vote from @GaelVaroquaux @vene @agramfort apart from Andy and Joel?

raghavrv · 2016-12-17T08:44:45Z

I'm not sure if this should be tagged a "bug" anymore. Removing "blocker" and "bug" labels...

raghavrv · 2016-12-27T07:33:16Z

Closing as #7941 is sufficient... Comment if you want this reopened...

Set a random random_state at init to ensure deterministic randomness

5dd260c

raghavrv mentioned this pull request Nov 24, 2016

[MRG + 2] FIX Be robust to non re-entrant/ non deterministic cv.split calls #7660

Merged

raghavrv added Blocker Bug labels Nov 24, 2016

raghavrv added this to the 0.18.2 milestone Nov 24, 2016

raghavrv changed the title ~~[MRG] Set a random random_state at init to ensure deterministic randomness~~ [MRG] Set a random random_state at init to ensure deterministic randomness when random_state is None Nov 24, 2016

raghavrv mentioned this pull request Nov 24, 2016

[architectural suggestion] Move random number generator to initializer in model_selection._split #6726

Closed

TomDLT reviewed Nov 25, 2016

View reviewed changes

raghavrv mentioned this pull request Nov 26, 2016

[MRG + 1] ENH Ensure consistency in splits and in parameters (without causing memory blowup because of materializing the iterator) #7941

Merged

COSMIT

75448b9

Use np.iinfo(...).max instead of 99999..

6f5947d

amueller requested changes Nov 28, 2016

View reviewed changes

jnothman requested changes Nov 28, 2016

View reviewed changes

amueller mentioned this pull request Dec 2, 2016

[WIP] Add repeated cross-validations #7960

Closed

Fix doctest

374d2ed

amueller reviewed Dec 3, 2016

View reviewed changes

raghavrv added 2 commits December 5, 2016 16:08

Change order instead of negating

d3db617

Comment clarity

c762363

raghavrv added 3 commits December 6, 2016 16:22

Modify random_state only when shuffle is set to True

318312e

Remove random_state param from example docs

a637c99

Simplify tests

bc9f22c

amueller reviewed Dec 6, 2016

View reviewed changes

amueller approved these changes Dec 6, 2016

View reviewed changes

amueller changed the title ~~[MRG] Set a random random_state at init to ensure deterministic randomness when random_state is None~~ [MRG + 1] Set a random random_state at init to ensure deterministic randomness when random_state is None Dec 6, 2016

raghavrv removed Blocker Bug labels Dec 17, 2016

raghavrv closed this Dec 27, 2016

raghavrv mentioned this pull request Jun 29, 2017

[MRG] Add few more tests + Documentation for re-entrant cross-validation estimators #7823

Merged

6 tasks

		for data in zip((X, X2), (y, y2)):
		# For the same initialilzation, splits should be same across

[MRG + 1] Set a random random_state at init to ensure deterministic randomness when random_state is None #7935

[MRG + 1] Set a random random_state at init to ensure deterministic randomness when random_state is None #7935

Conversation

raghavrv commented Nov 24, 2016 • edited Loading

In master (0.18.1)

In this branch, splits are different for multiple initializations of cross-validators but same across multiple split calls for the same initialization.

jnothman commented Nov 24, 2016

raghavrv commented Nov 24, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

raghavrv commented Nov 28, 2016

raghavrv commented Nov 28, 2016

amueller left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

raghavrv Nov 28, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lesteve Nov 29, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

raghavrv commented Nov 28, 2016

amueller commented Nov 28, 2016

amueller commented Nov 28, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

raghavrv commented Nov 28, 2016

amueller commented Nov 28, 2016

raghavrv commented Nov 28, 2016

raghavrv commented Nov 28, 2016

amueller commented Nov 28, 2016

raghavrv commented Nov 28, 2016 • edited Loading

jnothman commented Nov 28, 2016 via email

amueller commented Nov 28, 2016

raghavrv commented Nov 28, 2016

amueller commented Dec 2, 2016

raghavrv commented Dec 2, 2016

amueller commented Dec 2, 2016

amueller commented Dec 2, 2016 • edited Loading

raghavrv commented Dec 2, 2016

amueller left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

raghavrv Dec 5, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

raghavrv commented Dec 5, 2016

raghavrv commented Dec 6, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

[MRG + 1] Set a random random_state at init to ensure deterministic randomness when random_state is `None` #7935

[MRG + 1] Set a random random_state at init to ensure deterministic randomness when random_state is `None` #7935

raghavrv commented Nov 24, 2016 •

edited

Loading

raghavrv Nov 28, 2016 •

edited

Loading

lesteve Nov 29, 2016 •

edited

Loading

raghavrv commented Nov 28, 2016 •

edited

Loading

amueller commented Dec 2, 2016 •

edited

Loading

raghavrv Dec 5, 2016 •

edited

Loading