> Why do you want to rewrite the predict code, which seems to be already > working? > (Doesn't this further divergence from the libsvm code base just > increase the sklearn maintenance burden?) > > The key thing seems to be how heavily patched is the svm.cpp already? > If it's completely rewritten, then trying to work with the original > project is silly, but I don't think it is. It seems like there are a > few things: > > (1) the use of PREFIX and the _DENSE_REP ifdef, and the extra > double-include file that drives that mechanism > > (2) changing the upper_bound in solution_info to a buffer of len 2 > instead of 2 different variables > > (3) what looks like algorithmic changes around line 1600 that I don't > understand > > I could certainly be wrong, but these things still look maintainable > as a patch set. Why do you want to break further away from the libsvm > trunk, rather than refactor things to be, if anything, *more* > compatible with it? > I think the idea is that a lot of the code could be made more accessible and shorter by rewriting it using cython and numpy.
------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Scikit-learn-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
