To pitch in in this conversation, I do agree with Olivier that
reimplement libsvm or liblinear should not be our priorities, as we have
them, and they work reasonnably well. I agree with David that we would
need to garner more credibility (and I add more man power) to sustain
such an effort.
I am
2012/2/16 Mathieu Blondel :
> On Thu, Feb 16, 2012 at 7:50 PM, Olivier Grisel
> wrote:
>
>> Agreed but personally I would rather see such a GSoC student spend
>> time on writing a cython version of the LaSVM algorithm which looks
>> much more scalable than libsvm:
>
> I definitely want LaSVM in sc
On Thu, Feb 16, 2012 at 7:50 PM, Olivier Grisel
wrote:
> Agreed but personally I would rather see such a GSoC student spend
> time on writing a cython version of the LaSVM algorithm which looks
> much more scalable than libsvm:
I definitely want LaSVM in scikit-learn but IMO it's too small of a
2012/2/16 Mathieu Blondel :
> On Thu, Feb 16, 2012 at 3:43 PM, David Warde-Farley
> wrote:
>
>> I would stress that such an implementation would have to be extremely well
>> tested and checked against libsvm/liblinear in all of the relevant cases
>> (obviously, can't check against a float32 case
On Thu, Feb 16, 2012 at 3:43 PM, David Warde-Farley
wrote:
> I would stress that such an implementation would have to be extremely well
> tested and checked against libsvm/liblinear in all of the relevant cases
> (obviously, can't check against a float32 case if liblinear doesn't support
> flo
On 2012-02-16, at 2:03 AM, Mathieu Blondel wrote:
>> Well, it's a tradeoff: a good reimplementation that would approach the
>> original in terms of performance is a lot of work. For it to be
>> sustainable, the team would have to grow a fair amount.
>
> It is a lot of work but the bindings have
Nitpick: shouldn't it be "set_libsvm_stdout(True)" or "enable_libsvm_stdout() /
disable_libsvm_stdout()"?
Vlad
On Feb 15, 2012, at 13:30 , Alexandre Gramfort wrote:
>>> sklearn.svm.enable_libsvm_stdout(True)
>
> +1 too
>
> A
>
> ---
