2014-08-06 7:52 GMT+02:00 Joel Nothman <[email protected]>: > Instead, could we have an interface in which the `algorithm` parameter could > take any object supporting `fit(X)`, `query(X)` and `query_radius(X)`, such > as an LSHForest instance? Indeed you could also make 'lsh' an available > algorithm using reasonable parameters automatically inferred from the data, > but you certainly want the user to be able to control the LSH parameters.
I'd prefer just passing strings here, though. There aren't too many choices for the NN implementation, and accepting NN estimators complicates the client code and the documentation. Users would have to import from various places to assemble their own DBSCAN. If we denote NN implementations by strings + a dict for parameters, we can just enumerate the various options in the docstring without the need to introduce yet more conventions. This is obviously less generic, but I find it unlikely that we will add large numbers of NN implementations or that users will roll their own. ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ Scikit-learn-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
