Gael, Andreas,
Thank you for your comments.
> I'm not sure about the naming of the package. As long as there is no
> active involvement of the scikit-learn developers in this
> package, I'd rather not have "our" name on it.
I understand the concern.
There's a few machine learning packages that have attempted to define an
interface, but none of them have gathered any steam so far, and navigating
the ecosystem is painful. It's as much of a social problem as a technical
problem, and by broadcasting "This is the scikit-learn interface, I changed
it as little as possible", it has better chances of succeeding.
> Juliasklearn
I'm personally fine with that name, but the official guidelines (
http://docs.julialang.org/en/release-0.4/manual/packages/#guidelines-for-naming-a-package)
for package naming say:
"Avoid using Julia in your package name. It is usually clear from context
and to your users that the package is a Julia package."
"Packages that wrap external libraries or programs should be named after
those libraries or programs."
There is already Pandas.jl, Stan.jl, MATLAB.jl and Bokeh.jl following that
trend.
Maybe... NotScikitLearn.jl? ScikitForget.jl? :) It's tongue-in-cheek, but
IMO it communicates the right idea (like IceWeasel did)
> I worry like Andy of the overhead in support
What are you referring to? Do you mean that people might mistakenly file
issues with scikit-learn when they have problems in ScikitLearn.jl?
Best,
Cedric
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval
_______________________________________________
Scikit-learn-general mailing list
Scikit-learn-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
