Re: [Scikit-learn-general] Exclusivity of scikit-learn

I feel that maintaining package infrastructure is quite some work, if you want to have online documentation and continuous integration. It took me a day to build the pystruct docs after I tried to update the gallery from sklearn master. I guess that having an example repo that has a build, travi

Re: [Scikit-learn-general] Exclusivity of scikit-learn

> > On Dec 4, 2014, at 2:00 AM, Sturla Molden wrote: > > Tom Fawcett wrote: > >> Wow, I had not seen this FAQ. "As a rule we only add well-established >> algorithms. A rule of thumb is at least 3 years since publications, 1000+ >> cites and wide use and usefullness.” > > A dumping ground fo

Re: [Scikit-learn-general] Exclusivity of scikit-learn

Tom Fawcett wrote: > Wow, I had not seen this FAQ. "As a rule we only add well-established > algorithms. A rule of thumb is at least 3 years since publications, 1000+ > cites and wide use and usefullness.” A dumping ground for any kind of algorithm that "someone has found useful" is not a good

Re: [Scikit-learn-general] Exclusivity of scikit-learn

Chiming in as a user who never contributed but who uses sklearn a lot (yeah, I know, I need to find the time to help a a little), I tend to agree with this. I know a couple successful projects that have stand alone plugins, withwithv standardized names and interface and a easy to find curated list

Re: [Scikit-learn-general] Exclusivity of scikit-learn

2014-12-04 0:55 GMT+01:00 Joel Nothman : > For example, let's say someone has implemented an algorithm (Affinity > Propagation is what triggered this discussion so you might consider that). > Someone else wants to come and add features to it, or even just clean the > code, but by this time the orig

Re: [Scikit-learn-general] Exclusivity of scikit-learn

hi joel, I don't see what's hard about comparing models from outside scikit-learn, > on the assumption that all the packages worth comparing are trivial to > install, and listed in scikit-learn's "Extension Library". > i was referring to the scenario where this wasn't a standalone package but sim

Re: [Scikit-learn-general] Exclusivity of scikit-learn

I know what you mean by needing new features or refactoring inside the main project. I've got a case that requires a more polymorphic definition of sklearn.base.clone. I think such changes should be possible within the main repo, and need to be argued by their proponent, with tests documented to sa

Re: [Scikit-learn-general] Exclusivity of scikit-learn

hi gael and joel, i'll insert a short response here. i actually agree with all the things both of you said. i will however comment on two things: 1. algorithmic scenarios: a. adding algorithms that can be built directly of the scikit-learn api b. adding algorithms that require refactoring some n

Re: [Scikit-learn-general] Exclusivity of scikit-learn

Not really weighing in on this conversation, but this thread reminded me just how awesome sklearn is. *So many thanks* to everybody on this list who helps contribute, you all are awesome :) On Wed, Dec 3, 2014 at 3:55 PM, Joel Nothman wrote: > While anything is better than publishing an extended

Re: [Scikit-learn-general] Exclusivity of scikit-learn

While anything is better than publishing an extended fork of the main repository, I would like to see someone cite an instance where a open-slather contrib repository has been particularly successful (especially one where diverse contributions are assured). In line with Gaël's experience of sandbox

Re: [Scikit-learn-general] Exclusivity of scikit-learn

On Wed, Dec 03, 2014 at 09:56:55AM -0500, Satrajit Ghosh wrote: > - let the community (to put zero additional burden on the current maintainers) > maintain a fork of scikit-learn that provides no guarantees other than it is > kept upto date with scikit-learn/master.  The problem with this is that

Re: [Scikit-learn-general] Exclusivity of scikit-learn

On Wed, Dec 03, 2014 at 11:10:24AM -0500, Andy wrote: > For SAG I am not super sure it is a great example. It is a year old and > the same group already published two improvements to it. So it seems > obsolete before it is merged. Same feeling here, eventhought I have a personnal need for it. Th

Re: [Scikit-learn-general] Exclusivity of scikit-learn

On 12/03/2014 04:04 AM, Mathieu Blondel wrote: > I think 1000 citations is a bit too much to ask. We should probably > update the FAQ with something more reasonable, like say 200 citations. > That said, I agree that the citation threshold is just an indicator. > For example, SAG and AdaGrad, wh

Re: [Scikit-learn-general] Exclusivity of scikit-learn

I really want to push this approach, and hope I have time to establish it early next year. And I think that a zero-intersection approach would be better than a fork, as it avoids incompatible changes. On 12/03/2014 10:31 AM, Mathieu Blondel wrote: As you mentioned popular methods from scikit-

Re: [Scikit-learn-general] Exclusivity of scikit-learn

As you mentioned popular methods from scikit-learn-contrib could be promoted to scikit-learn. Conversely, methods which became obsolete in scikit-learn could move to scikit-learn-contrib to lower the maintenance burden. Mathieu On Thu, Dec 4, 2014 at 12:26 AM, Mathieu Blondel wrote: > Hi Satra

Re: [Scikit-learn-general] Exclusivity of scikit-learn

Hi Satra, I can't find the link but there was a discussion some time ago about creating a scikit-learn-contrib organization on github for this purpose. Two differences with what you suggest: 1) this wouldn't be a fork, i.e., the intersection with scikit-learn would be empty 2) we were thinking of

Re: [Scikit-learn-general] Exclusivity of scikit-learn

hi folks, since this comes up from time to time and i completely understand the needed focus and limited resources within scikit-learn, how about the following approach: - let the community (to put zero additional burden on the current maintainers) maintain a fork of scikit-learn that provides no

Re: [Scikit-learn-general] Exclusivity of scikit-learn

> I agree. We should ammend this sentence to say that if the paper is an > clear-cut improvement on top of a very used method, it should be > examinded. Done . On 3 December 2014 at 20:07, Gael Varoquaux wrote: > On Wed, Dec 03, 2014 at 06:04:58PM +0900,

Re: [Scikit-learn-general] Exclusivity of scikit-learn

On Wed, Dec 03, 2014 at 06:04:58PM +0900, Mathieu Blondel wrote: > I think 1000 citations is a bit too much to ask. We should probably > update the FAQ with something more reasonable, like say 200 citations. > That said, I agree that the citation threshold is just an indicator. > For example, SAG a

Re: [Scikit-learn-general] Exclusivity of scikit-learn

On Wed, Dec 3, 2014 at 4:09 PM, Joel Nothman wrote: > Hi Tom, > > Anyone is welcome to publish their implementations in a format compatible > with scikit-learn's estimators. However, the centralised project already > takes a vast amount of work (almost all of it unpaid) to maintain, even > while

Re: [Scikit-learn-general] Exclusivity of scikit-learn

Hi Tom, If I might add a suggestion: I think it would be great if you developed these ideas in a separate repository, made the API compatible with scikit-learn, and released the code on PyPI. Then it will be out there and available to anyone who wants to use it. That's what I've ended up doing at t

Re: [Scikit-learn-general] Exclusivity of scikit-learn

I think the crux is this: *From my use of scikit-learn I view it more as a CRAN or CPAN (or PyPi) ecosystem: it’s a fairly loose framework supporting many plug-in modules of varying quality.* scikit-learn is not itself an ecosystem - it is a single package within the ecosystem, and the leaders of

Re: [Scikit-learn-general] Exclusivity of scikit-learn

On Wed, Dec 03, 2014 at 12:12:41AM -0800, Tom Fawcett wrote: > From my use of scikit-learn I view it more as a CRAN or CPAN (or PyPi) > ecosystem: That's because you are not on the receiving end when there is a problem with something coded in scikit-learn. The equivalent of CRAN is PyPi: there are

Re: [Scikit-learn-general] Exclusivity of scikit-learn

> The bottom line is that you or anyone else is welcome to fork the project and > be as welcoming as you like. But the project thrives on the basis that it is > well-contained and well-maintained, and that simply can't be assured of a > project without restrictive criteria for inclusion. I thin

Re: [Scikit-learn-general] Exclusivity of scikit-learn

Hi Tom, Anyone is welcome to publish their implementations in a format compatible with scikit-learn's estimators. However, the centralised project already takes a vast amount of work (almost all of it unpaid) to maintain, even while adopting a very restrictive scope. Incorporating less-established

Re: [Scikit-learn-general] Exclusivity of scikit-learn

On Tue, Dec 02, 2014 at 08:32:45PM -0800, Tom Fawcett wrote: > Anyone know of another python framework that’s a little more welcoming? Well, packages need a decision rule to filter out the massive amount of published algorithms, and implementing and doing maintainance on the complete literature is

[Scikit-learn-general] Exclusivity of scikit-learn

> On Dec 2, 2014, at 6:34 AM, Andy wrote: > > Hi Ilya. > > Thanks for your interest in contributing. > I am not expert in affinity propagation, so it would be great if you could > give some details of what the advantage of the method is. > The reference paper seems to be an arxiv preprint with