octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: svmtrain/svmclassify


From: Juan Pablo Carbajal
Subject: Re: svmtrain/svmclassify
Date: Sun, 9 Dec 2012 20:49:30 +0100

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]