On 22 August 2013 14:38, Björn Esser <bjoern.es...@gmail.com> wrote:

> Am Donnerstag, den 22.08.2013, 14:22 +0200 schrieb Lars Buitinck:
> > 2013/8/22 Olivier Grisel <olivier.gri...@ensta.org>:
> > > 2013/8/22 Björn Esser <bjoern.es...@gmail.com>:
> > >> Can you please tell me a bit more about what / why these were modded?
> > >> If we cannot unbundle them, I need to have some further infos to get
> > >> some exception granted for them. :)
> > >
> > > For the libsvm binding the main reason it to get both the sparse and
> > > dense memory layout for the input data. The upstream package only
> > > supports sparse input data and the dense variant lives in a 3rd party
> > > fork:
> > [snip]
> > > For liblinear I am not sure anymore (I was not personally involved in
> > > those bindings). It's probably worth exploring with diff of the source
> > > folders.
> >
> > We also added RNG seeding to both LibSVM and Liblinear, so the API and
> > calling interface are different from upstream. We also fixed a couple
> > of bugs and swapped +1 and -1 in some places to match our conventions
> > better. The RNG seeding is important for reproducible results (e.g.,
> > to make the tests pass reliably).
>
> Not a hint of that in liblinear code... :)
>
> > The main changes to Liblinear can be seen with gitk
> > sklearn/svm/src/liblinear/linear.cpp in the scikit-learn source
> > directory. We have 1.91, btw.
>
> There are ~30 lines added and ~5 lines reordered as I see.
>
> > Björn, I'm not sure how strict the Fedora people are when it comes to
> > packaged dependencies, but you could say that we don't really ship
> > LibSVM and Liblinear; we ship derivatives.
>
> I doubt getting an exception for liblinear, because there no significant
> change on it.  But as I am the maintainer of liblinear, I can get your
> patches / changeset applied on pristine sources of liblinear and build a
> `liblinear-scikitmod` to link against
>

Nothing significant. Just significant enough that it will break
scikit-learn not to use our version.
Considering how we bundle and patched liblinear, there's no chance to come
into conflict with another version. I don't see the point in creating a
whole package considering how complex it is, and the maintenance burden.

I think we should stop mentioning we ship liblinear and libsvm, and
consider those as forks.


>
> Thanks for your hints.
>
> Cheers,
>   Björn
>
>
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> Scikit-learn-general mailing list
> Scikit-learn-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
>
------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
Scikit-learn-general mailing list
Scikit-learn-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scikit-learn-general

Reply via email to