Hi All, Thanks a lot for your responses.
Gaël : Certainly not looking to break any openness or trust, that's why I
asked :-) After a bit more thought on the font issue, I think the danger of
implying my package is reviewed/endorsed by scikit-learn is too great with
the graphic similarities that yo
On 04/28/2015 09:49 AM, Olivier Grisel wrote:
> Note that Trevor already tries to automate checks for semantic
> compatibility by leveraging
> Andy's estimator checks utility when possible:
>
> https://github.com/trevorstephens/gplearn/blob/master/gplearn/tests/test_common.py
>
> This can probabl
Note that Trevor already tries to automate checks for semantic
compatibility by leveraging
Andy's estimator checks utility when possible:
https://github.com/trevorstephens/gplearn/blob/master/gplearn/tests/test_common.py
This can probably be improved (on both sides) but it's a great start!
As fo
Hi Trevor,
This is an interesting question, and I don't have a clear cut opinion.
What you are talking about is, in essence a trademark issue: the brand
"scikit-learn", carries implications about quality and API. We enforce
this on the scikit-learn package and would indeed love if the users
assoc
Hi Trevor,
I am only speaking for myself, not on behalf of the scikit-learn project,
but I would be +1 for your project and use of the -learn suffix. The pros
you cite are in my opinion more important than the cons.
Cheers,
Gilles
On 28 April 2015 at 05:33, Trevor Stephens wrote:
> Hi All,
>
>
Hi All,
I've been working for the past month or so on a third-party add-on/plug-in
package `gplearn` that uses the scikit-learn API to implement genetic
programming for symbolic regression tasks in Python and maintains
compatibility with the sklearn pipeline and gridsearch modules, etc. The
reason
