On Sun, Dec 9, 2012 at 8:28 PM, Carnë Draug<address@hidden> wrote:
On 9 December 2012 14:43, Juan Pablo Carbajal<address@hidden> wrote:
On Sat, Dec 8, 2012 at 11:33 PM, Carnë Draug<address@hidden> wrote:
On 8 December 2012 23:20, Ben P<address@hidden> wrote:
I recently did a support vector machine project. It's at the point where I
don't think it'd be too much more work to add a simple svmtrain/svmclassify
to Octave.
Would there be any interest in something like this? What package would it
belong in? I didn't notice a machine learning package.
Hi Ben
in Matlab these two functions appear to be in the bioinformatics
toolbox so my guess is that it would also go in the bioinfo package.
The package is currently unmaintained but if you submit those two
functions I'd be happy to include them.
Carnë
I do not think support vector machines would be easy, nor natural to
find in the bioinformatics package.
When a function exists in a matlab toolbox, this has been the rule for
the decision in which package it goes. If not, look at all the
functions that no longer make sense. For example, minmax (nnet),
in2vec (nnet), isposint (nnet), iptchecknargin (image), iptnum2ordinal
(image). I'm sure there are many others. The idea is that if someone
knows a function exists in matlab, then it already knows in what
package to look for it. Unless we change the decision factor, in which
case we'd need to move a lot of functions around, and fix
dependencies.
Carnë
Hi Carnë
I totally disagree with that policy. We have to provide a good way to
search for functions, not to stick t the braindead way of classifying
functions in matlab. SVM is a machine learning technique, it maybe
used in biology, but it is also used, for example in physics, so it
makes no sense to put it in any discipline that just uses the tool.
Unless the decision can be justified with something more than "because
matlab does it", I see really no point in putting svm inside
bioinformatics.
Regarding moving functions that are already located. On basis on "man
power" it doesn't make any sense, leave them there and lets improve
from now on. On basis of user already using the package to get the
function, you will break code unnecessarily. Also forcing all that
work will reduce productivity.
My suggested rule: Fix from now on, go back eventually