

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.
Ben Pheil


On 8 December 2012 23:20, Ben P < [hidden email]> 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ë


On Sat, Dec 8, 2012 at 11:33 PM, Carnë Draug < [hidden email]> wrote:
> On 8 December 2012 23:20, Ben P < [hidden email]> 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.
I would suggest to merge nnet and svm into a single package called
machinelearning.
Remember that the packages do allow to have subfolders so the
packages can be merged transparently.
So we could have
main
__ machinelearning
__ inst
__ svm
__ nnet
__ gp (gaussian processes, comming soon)
What do you think?
I can help with the merging, I have done it before.


On 12/09/2012 07:43 AM, Juan Pablo Carbajal wrote:
> On Sat, Dec 8, 2012 at 11:33 PM, Carnë Draug< [hidden email]> wrote:
>> On 8 December 2012 23:20, Ben P< [hidden email]> 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.
>
> I would suggest to merge nnet and svm into a single package called
> machinelearning.
I was going to suggest this as well. This also reflects the trend in
technical literature where SVM now seems to have a presence in what used
to be mostly ANN (e.g., IEEE Transaction on Neural Networks and Learning
Systems).
The other logical place for SVM would be optimization because at the
core of SVM is typically a quadratic programming problem with a Lagrangian.
Dan


In reply to this post by Juan Pablo Carbajal2
On 9 December 2012 14:43, Juan Pablo Carbajal < [hidden email]> wrote:
> On Sat, Dec 8, 2012 at 11:33 PM, Carnë Draug < [hidden email]> wrote:
>> On 8 December 2012 23:20, Ben P < [hidden email]> 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ë


On Sun, Dec 9, 2012 at 8:28 PM, Carnë Draug < [hidden email]> wrote:
> On 9 December 2012 14:43, Juan Pablo Carbajal < [hidden email]> wrote:
>> On Sat, Dec 8, 2012 at 11:33 PM, Carnë Draug < [hidden email]> wrote:
>>> On 8 December 2012 23:20, Ben P < [hidden email]> 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


Clearly there are many functions that would be relevant to more than
one Forge package. Would it be possible to have a package suggest
related functions in other packages?


In reply to this post by Juan Pablo Carbajal2
On 12/09/2012 01:49 PM, Juan Pablo Carbajal wrote:
> On Sun, Dec 9, 2012 at 8:28 PM, Carnë Draug< [hidden email]> wrote:
>> On 9 December 2012 14:43, Juan Pablo Carbajal< [hidden email]> wrote:
>>> On Sat, Dec 8, 2012 at 11:33 PM, Carnë Draug< [hidden email]> wrote:
>>>> On 8 December 2012 23:20, Ben P< [hidden email]> 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
I agree that organizing packages on the basis of Matlab's organization
isn't necessary. The problem is that to do so ventures outside of
syntax compatibility and into the area of marketing. I suspect that
Mathworks makes some decisions on package content driven by marketing,
e.g., spread things around a bit and make all packages attractive to
wider audiences.
I'd prefer things organized by category in a logical fashion.
Dan


On 12/09/2012 01:58 PM, Nir Krakauer wrote:
> Clearly there are many functions that would be relevant to more than
> one Forge package. Would it be possible to have a package suggest
> related functions in other packages?
That's what documentation is for, but also knowledge and experience on
part of the user helps. Searching the list of functions on the
OctaveForge page is always helpful and quick.
Dan


On 9 December 2012 20:49, Juan Pablo Carbajal < [hidden email]> wrote:
> 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.
On 9 December 2012 21:17, Daniel J Sebald < [hidden email]> wrote:
> I agree that organizing packages on the basis of Matlab's organization isn't
> necessary.
Indirectly, this is the same policy/organization that decides if a
function should go into an Octave Forge package or into Octave core.
Carnë


On 12/09/2012 03:59 PM, Carnë Draug wrote:
> On 9 December 2012 20:49, Juan Pablo Carbajal< [hidden email]> wrote:
>> 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.
>
> On 9 December 2012 21:17, Daniel J Sebald< [hidden email]> wrote:
>> I agree that organizing packages on the basis of Matlab's organization isn't
>> necessary.
>
> Indirectly, this is the same policy/organization that decides if a
> function should go into an Octave Forge package or into Octave core.
I'm not understanding. What is the same policy? How so indirectly?
Dan


On 9 December 2012 23:14, Daniel J Sebald < [hidden email]> wrote:
> On 12/09/2012 03:59 PM, Carnė Draug wrote:
>>
>> On 9 December 2012 20:49, Juan Pablo Carbajal< [hidden email]>
>> wrote:
>>>
>>> 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.
>>
>>
>> On 9 December 2012 21:17, Daniel J Sebald< [hidden email]> wrote:
>>>
>>> I agree that organizing packages on the basis of Matlab's organization
>>> isn't
>>> necessary.
>>
>>
>> Indirectly, this is the same policy/organization that decides if a
>> function should go into an Octave Forge package or into Octave core.
>
> I'm not understanding. What is the same policy? How so indirectly?
We have been following Mathworks' organization of functions not only
to decide in which package a function should go, but also if it should
go into core or into forge.
This means that if someone submits a new function that does not exist
in a matlab toolbox, the decision lies in how "general" or useful that
function is, and how committed that person is to maintain the
submitted code. However, if the function already exists in a matlab
toolbox we don't care about this anymore, it just goes to a forge
package. Even though a function that mathworks bothered to implement,
even if only in one of their toolboxes, is likely to be something more
people use. And if it was written by a forge developer, then they are
also some of the most committed to maintain the code. This only makes
sense because we follow matlab organization.
Now, Octave can't become a collection of all Octave code that is out
there, but if we decide to say "screw matlab, their organization
doesn't make sense. This function should go into some more appropriate
package" then we can also start saying "screw matlab, their
organization doesn't make sense. This function is to broad and should
should go into core, not into a package".
And of course, broad, general use, more useful, etc can be relative.
But so can be the area or field of a specific function.
Carnë


On Sun, Dec 9, 2012 at 3:41 PM, Carnë Draug <[hidden email]> wrote:
On 9 December 2012 23:14, Daniel J Sebald < [hidden email]> wrote:
> On 12/09/2012 03:59 PM, Carnė Draug wrote:
>>
>> On 9 December 2012 20:49, Juan Pablo Carbajal< [hidden email]>
>> wrote:
>>>
>>> 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.
I don't see why we can't stick with the matlab classification as long a we have a really good search capability in forge (or agora)  that is far more important
 Ed Meyer


On Mon, Dec 10, 2012 at 5:02 AM, Ed Meyer < [hidden email]> wrote:
>
>
> On Sun, Dec 9, 2012 at 3:41 PM, Carnë Draug < [hidden email]> wrote:
>>
>> On 9 December 2012 23:14, Daniel J Sebald < [hidden email]> wrote:
>> > On 12/09/2012 03:59 PM, Carnė Draug wrote:
>> >>
>> >> On 9 December 2012 20:49, Juan Pablo Carbajal< [hidden email]>
>> >> wrote:
>> >>>
>> >>> 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.
>
>
> I don't see why we can't stick with the matlab classification as long a we
> have
> a really good search capability in forge (or agora)  that is far more
> important
>
> 
> Ed Meyer
>
Do as you want a the end your are leading OF. In any case I invite you
to read your arguments carefully and realize that ther eis really n
reason to follow such policy. Indeed it even doesn't stand to reasons!
What are the advantages?
A dialogue:
"
from [hidden email]
to [hidden email]
Hi,
I am trying to run some machine learning algorithms and compare with
standard classification tools as svm. What package should install?
from [hidden email]
to [hidden email], [hidden email]
You can get svm form the bioinformatics package
"
Yeah, that sound like a display of good organization and cleverness!
Once again I fail to understand the point of restricting ourselves by
matlab decisions. We could improve were possible, and i this case we
can, unless you have another reason but the mere "they do it like
that". This is totally hindering the evolution of the software!
If you stick too much to what is called braindead (yeah, that is an
official flag), where do you think you are going to end?
My two cents.
JPi


On Mon, Dec 10, 2012 at 6:53 AM, Juan Pablo Carbajal
< [hidden email]> wrote:
> On Mon, Dec 10, 2012 at 5:02 AM, Ed Meyer < [hidden email]> wrote:
>>
>>
>> On Sun, Dec 9, 2012 at 3:41 PM, Carnë Draug < [hidden email]> wrote:
>>>
>>> On 9 December 2012 23:14, Daniel J Sebald < [hidden email]> wrote:
>>> > On 12/09/2012 03:59 PM, Carnė Draug wrote:
>>> >>
>>> >> On 9 December 2012 20:49, Juan Pablo Carbajal< [hidden email]>
>>> >> wrote:
>>> >>>
>>> >>> 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.
>>
>>
>> I don't see why we can't stick with the matlab classification as long a we
>> have
>> a really good search capability in forge (or agora)  that is far more
>> important
>>
>> 
>> Ed Meyer
>>
>
> Do as you want a the end your are leading OF. In any case I invite you
> to read your arguments carefully and realize that ther eis really n
> reason to follow such policy. Indeed it even doesn't stand to reasons!
> What are the advantages?
> A dialogue:
>
> "
> from [hidden email]
> to [hidden email]
>
> Hi,
> I am trying to run some machine learning algorithms and compare with
> standard classification tools as svm. What package should install?
>
> from [hidden email]
> to [hidden email], [hidden email]
>
> You can get svm form the bioinformatics package
> "
>
> Yeah, that sound like a display of good organization and cleverness!
>
> Once again I fail to understand the point of restricting ourselves by
> matlab decisions. We could improve were possible, and i this case we
> can, unless you have another reason but the mere "they do it like
> that". This is totally hindering the evolution of the software!
> If you stick too much to what is called braindead (yeah, that is an
> official flag), where do you think you are going to end?
>
> My two cents.
>
> JPi
I may have sounded rude when I said
"Do as you want a the end your are leading OF"
I was just trying to say that Carnë has the last word here, but that
if we stick to matlab organization I am not happy
Cheers


On 12/09/2012 05:41 PM, Carnë Draug wrote:
> On 9 December 2012 23:14, Daniel J Sebald< [hidden email]> wrote:
>> On 12/09/2012 03:59 PM, Carnė Draug wrote:
>>>
>>> On 9 December 2012 20:49, Juan Pablo Carbajal< [hidden email]>
>>> wrote:
>>>>
>>>> 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.
>>>
>>>
>>> On 9 December 2012 21:17, Daniel J Sebald< [hidden email]> wrote:
>>>>
>>>> I agree that organizing packages on the basis of Matlab's organization
>>>> isn't
>>>> necessary.
>>>
>>>
>>> Indirectly, this is the same policy/organization that decides if a
>>> function should go into an Octave Forge package or into Octave core.
>>
>> I'm not understanding. What is the same policy? How so indirectly?
>
> We have been following Mathworks' organization of functions not only
> to decide in which package a function should go, but also if it should
> go into core or into forge.
>
> This means that if someone submits a new function that does not exist
> in a matlab toolbox, the decision lies in how "general" or useful that
> function is, and how committed that person is to maintain the
> submitted code. However, if the function already exists in a matlab
> toolbox we don't care about this anymore, it just goes to a forge
> package. Even though a function that mathworks bothered to implement,
> even if only in one of their toolboxes, is likely to be something more
> people use. And if it was written by a forge developer, then they are
> also some of the most committed to maintain the code. This only makes
> sense because we follow matlab organization.
>
> Now, Octave can't become a collection of all Octave code that is out
> there, but if we decide to say "screw matlab, their organization
> doesn't make sense. This function should go into some more appropriate
> package" then we can also start saying "screw matlab, their
> organization doesn't make sense. This function is to broad and should
> should go into core, not into a package".
Sure, but a bit less of the pejorative. I'm simply recognizing that
Mathworks has an objective that is perhaps different from that here.
Their objective is to sell software and services, so the way in which
they organize packages makes sense with respect to that objective.
Software companies do this by supplying enough functionality in the base
to make the software usable for some things, then sell more software as
addons and in this case distribute the features amongst packages so
that no one package becomes huge and thereby too expensive or so small
that it is unattractive as a product.
> And of course, broad, general use, more useful, etc can be relative.
> But so can be the area or field of a specific function.
With thousands of users and researchers enough of the randomness is
factored out to make it a fairly easy task to categorize something as of
general use or more specific use.
Dan


On 09/12/2012 23:41, Carnë Draug wrote:
> On 9 December 2012 23:14, Daniel J Sebald < [hidden email]> wrote:
>> On 12/09/2012 03:59 PM, Carnė Draug wrote:
>>>
>>> On 9 December 2012 20:49, Juan Pablo Carbajal< [hidden email]>
>>> wrote:
>>>>
>>>> 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.
>>>
>>>
>>> On 9 December 2012 21:17, Daniel J Sebald< [hidden email]> wrote:
>>>>
>>>> I agree that organizing packages on the basis of Matlab's organization
>>>> isn't
>>>> necessary.
>>>
>>>
>>> Indirectly, this is the same policy/organization that decides if a
>>> function should go into an Octave Forge package or into Octave core.
>>
>> I'm not understanding. What is the same policy? How so indirectly?
>
<snip>
> Now, Octave can't become a collection of all Octave code that is out
> there, but if we decide to say "screw matlab, their organization
> doesn't make sense. This function should go into some more appropriate
> package" then we can also start saying "screw matlab, their
> organization doesn't make sense. This function is to broad and should
> should go into core, not into a package".
>
> And of course, broad, general use, more useful, etc can be relative.
> But so can be the area or field of a specific function.
>
> Carnë
>
Are there reasons not to have packages depend upon one another, or
technical reasons this would be very difficult to implement
(embarrassingly I don't know if this is already done)?
A specialised bioinformatics package that depends on a more general
machine learning package makes sense to me, but I'm sure others have
thought this through already and found it difficult to achieve in practice?
This would allow OctaveForge to have Matlab's organisation, and a
sensible organisation too. Packages that make up equivalents of ML's
toolboxes could be made up almost entirely of dependency lists, plus
maybe a few extra functions.
Richard

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


On Mon, Dec 10, 2012 at 3:36 PM, Richard Crozier < [hidden email]> wrote:
> On 09/12/2012 23:41, Carnë Draug wrote:
>>
>> On 9 December 2012 23:14, Daniel J Sebald < [hidden email]> wrote:
>>>
>>> On 12/09/2012 03:59 PM, Carnė Draug wrote:
>>>>
>>>>
>>>> On 9 December 2012 20:49, Juan Pablo Carbajal< [hidden email]>
>>>> wrote:
>>>>>
>>>>>
>>>>> 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.
>>>>
>>>>
>>>>
>>>> On 9 December 2012 21:17, Daniel J Sebald< [hidden email]>
>>>> wrote:
>>>>>
>>>>>
>>>>> I agree that organizing packages on the basis of Matlab's organization
>>>>> isn't
>>>>> necessary.
>>>>
>>>>
>>>>
>>>> Indirectly, this is the same policy/organization that decides if a
>>>> function should go into an Octave Forge package or into Octave core.
>>>
>>>
>>> I'm not understanding. What is the same policy? How so indirectly?
>>
>>
> <snip>
>
>> Now, Octave can't become a collection of all Octave code that is out
>> there, but if we decide to say "screw matlab, their organization
>> doesn't make sense. This function should go into some more appropriate
>> package" then we can also start saying "screw matlab, their
>> organization doesn't make sense. This function is to broad and should
>> should go into core, not into a package".
>>
>> And of course, broad, general use, more useful, etc can be relative.
>> But so can be the area or field of a specific function.
>>
>> Carnë
>>
>
> Are there reasons not to have packages depend upon one another, or technical
> reasons this would be very difficult to implement (embarrassingly I don't
> know if this is already done)?
>
> A specialised bioinformatics package that depends on a more general machine
> learning package makes sense to me, but I'm sure others have thought this
> through already and found it difficult to achieve in practice?
>
> This would allow OctaveForge to have Matlab's organisation, and a sensible
> organisation too. Packages that make up equivalents of ML's toolboxes could
> be made up almost entirely of dependency lists, plus maybe a few extra
> functions.
>
> Richard
>
>
>
>
>
>
>
> 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
Yes, packages can depend on other packages that is already
implemented. At installation time the dependencies are not solved
automatically (unless you are using a package manager from your OS)
but we are working on it.


On 8 December 2012 22:20, Ben P < [hidden email]> 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
did you ever managed to get around implementing this functions?
Carnë

