Re: svmtrain/svmclassify

[Juan Pablo Carbajal]

On Mon, Dec 10, 2012 at 3:36 PM, Richard Crozier <address@hidden> wrote:
> On 09/12/2012 23:41, Carnë Draug wrote:
>>
>> On 9 December 2012 23:14, Daniel J Sebald <address@hidden> wrote:
>>>
>>> On 12/09/2012 03:59 PM, Carnė Draug wrote:
>>>>
>>>>
>>>> On 9 December 2012 20:49, Juan Pablo Carbajal<address@hidden>
>>>> 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<address@hidden>
>>>> 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 Octave-Forge 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.