On Thu, May 24, 2012 at 5:49 PM, Andreas Mueller <[email protected]> wrote: > Hey Ian. > Sorry for being a bit absent from this discussion but I didn't think so > much mail > would accumulate over one afternoon not in the office. > > The ``coef_`` code was written quite recently by me. Before it was just > buggy. > It was a bit tricky because of the weird format that LibSVM puts the > alphas in > in the multi-class case. If I understood you correctly, though, there is no > real bug, right?
Yes, in the end there is not a bug :) > > I am +1 on using the primal formulation for "predict" in the linear case > and I am +1 for computing "coef_" in "fit". It doesn't need to be a > property any more, then, right? Or was there some other magic attached? As long as "fit" is the only code that can modify dual_coefs_ and support_vectors_, then it is safe for fit to also compute coef_ and make it not a property. We can just set it to None if kernel != 'linear'. But I don't know for sure that "fit" is the only thing that can modify the SVM's decision function. If we are confident "fit" is the only thing that modify's the SVM's decision function, and that no new functions that modify it are likely to be introduced later, then I can go ahead and move the coef_ logic there. > > I didn't do this in the first place because I thought this would be > unnecessary > overhead. Though if "coef_" is used in predict any way, it is no > overhead at all. > > So a pull request doing this would be very welcome. > I am a bit busy atm with the approaching NIPS deadline but I can > review after that if no one else has time before. > > Cheers, > Andy > > > On 05/24/2012 11:35 PM, Ian Goodfellow wrote: >> On Thu, May 24, 2012 at 5:09 PM, Gael Varoquaux >> <[email protected]> wrote: >>> On Thu, May 24, 2012 at 05:07:59PM -0400, David Warde-Farley wrote: >>>> An alternative might be to just compute it in fit() if kernel == 'linear', >>>> and make the property function return the precomputed vector in that case. >>>> That probably minimizes the number of bugs introduced by either neglecting >>>> to >>>> update current functionality to use the dirty bit or future, orthogonal >>>> functionality forgetting to respect the dirty bit. >>> I think that I would actually prefer this option. >> OK--you are aware that coef_ is only defined in the case where kernel >> == 'linear', >> right? So the property would basically become nothing more than check on that >> condition, followed by returning the value computed by fit. >> >> >> > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Scikit-learn-general mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/scikit-learn-general ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Scikit-learn-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
