Congrats !
Bertrand
On 29/09/2016 07:28, Gael Varoquaux wrote:
Hurray!
Congratulations to everybody, and in particular the release time!
Gaël
On Wed, Sep 28, 2016 at 05:01:45PM -0400, Andreas Mueller wrote:
Hi everybody.
I'm happy to announce scikit-learn 0.18 has been released today.
You c
Have been playing around with the new functionality tonight. There are so many
great additions, especially the new CV functionality in the model_selection
module is super great. Nested CV is much more convenient now! Congratulations
to everyone, and thanks for this great new version! :)
> On S
Hurray!
Congratulations to everybody, and in particular the release time!
Gaël
On Wed, Sep 28, 2016 at 05:01:45PM -0400, Andreas Mueller wrote:
> Hi everybody.
> I'm happy to announce scikit-learn 0.18 has been released today.
> You can install from pipy or anaconda.org:
> pip install --upgrad
On 29 September 2016 at 01:47, Nelle Varoquaux
wrote:
> On 28 September 2016 at 08:18, Andreas Mueller wrote:
> >
> >
> > On 09/28/2016 10:05 AM, Gael Varoquaux wrote:
> >>
> >> I am not against it. When I think about why I didn't use it, it was a
> >> combination of laziness and lack of trust i
Hi everybody.
I'm happy to announce scikit-learn 0.18 has been released today.
You can install from pipy or anaconda.org:
pip install --upgrade scikit-learn --no-deps
or if you prefer conda:
conda update scikit-learn
A big thank you to everybody who contributed.
This one took us a while, bu
On 28 September 2016 at 12:24, Andreas Mueller wrote:
>
>
> On 09/28/2016 02:21 PM, Nelle Varoquaux wrote:
>>
>>
>> I think the only ones worth having are the ones that can be dealt with
>> automatically and the ones that will not be used frequently:
>>
>> - stalled after 30 days of inactivity [ca
On 09/28/2016 02:21 PM, Nelle Varoquaux wrote:
I think the only ones worth having are the ones that can be dealt with
automatically and the ones that will not be used frequently:
- stalled after 30 days of inactivity [can be done automatically]
- in dispute [I don't expect it to be used often
On 28 September 2016 at 10:09, Nelson Liu wrote:
> Maybe something for "stalled" pull requests? e.g. if someone hasn't worked
> on their PR in say 30 days and it's tagged "waiting for changes", you could
> ping them and then put on the "stalled" label. If they don't respond in
> another 15 days /
Maybe something for "stalled" pull requests? e.g. if someone hasn't worked
on their PR in say 30 days and it's tagged "waiting for changes", you could
ping them and then put on the "stalled" label. If they don't respond in
another 15 days / say they aren't working on it anymore, maybe it'd be good
So following up on this conversation, do we want to use status labels
more consistently?
And what should they be?
Joel Proposed for PRs:
* WIP (not ready for review)
* waiting for review [we have a tag for this]
* waiting for changes (with or without one of the following)
* in dispute (i.e. fund
On 28 September 2016 at 08:18, Andreas Mueller wrote:
>
>
> On 09/28/2016 10:05 AM, Gael Varoquaux wrote:
>>
>> I am not against it. When I think about why I didn't use it, it was a
>> combination of laziness and lack of trust in git (ie I was worried of
>> hard-to-resolve conflicts).
>
> Cool.
>
Afarin,
can you please describe your full data set, as maybe you are making a
mistake in how you are setting up the data.
My understanding of what Afarin is saying is that for each person he has a
row for successes and a row for failures (but cannot understand why only
two rows - would expect mult
It's not really clear to me what you want to achieve.
What do you mean by "does not lead to a biased accuracy"?
On 09/26/2016 05:06 PM, Afarin Famili wrote:
Hi David,
When applying Train_test_split to the sample space, we have a single row per
subject. I am looking for some other function lik
On 09/28/2016 10:05 AM, Gael Varoquaux wrote:
I am not against it. When I think about why I didn't use it, it was a
combination of laziness and lack of trust in git (ie I was worried of
hard-to-resolve conflicts).
Cool.
I think we didn't run into any problems with it so far, and we have used
i
> When doing some backports, I realized that some people (including Gael)
> didn't use it.
I am not against it. When I think about why I didn't use it, it was a
combination of laziness and lack of trust in git (ie I was worried of
hard-to-resolve conflicts).
__
That's generally my approach too. Squash and merge unless you need a record
of separate authorship.
Squashing helps managing cherrypicking for releases, and ensuring what's
new has decent coverage.
On 29 September 2016 at 00:02, Andreas Mueller wrote:
> Hey.
>
> This is a continuation of the di
Hey.
This is a continuation of the discussion we had on squashing in June:
https://mail.python.org/pipermail/scikit-learn/2016-June/000121.html
I thought we discussed this again after the "squash and merge" feature
was introduced, but I couldn't find the thread.
I think Joel, me and some othe
17 matches
Mail list logo
