Re: [shogun] About CBinaryLabels and CMultilabelLabels

Thank you Heiko and Fernando! Sorry for the late reply. @Heiko But we already have CLabels as base class of all other label classes. Do we need to reconstruct to CLabels we have? 2017-05-30 1:59 GMT+08:00 Heiko Strathmann : > Yes that's what I mean, just like we

Re: [shogun] About CBinaryLabels and CMultilabelLabels

Yes that's what I mean, just like we discussed for features in Zurich Not documented... H On Mon, 29 May 2017 at 11:52, Fernando J. Iglesias García < fernando.iglesi...@gmail.com> wrote: > @Heiko, I think this is a good idea. If I understand it correctly, you > suggest that the api has access

Re: [shogun] About CBinaryLabels and CMultilabelLabels

@Heiko, I think this is a good idea. If I understand it correctly, you suggest that the api has access to only one class for labels and then Shogun (internally) figures out what label type (private for the api) should be used (based on the input data, or in the learning algorithm once they need to

Re: [shogun] About CBinaryLabels and CMultilabelLabels

On 29 May 2017 at 08:27, Tiramisu Ling wrote: > Hi, I have a question about the difference between CBinaryLabels > and CMultilabelLabels. Why we need to make CBinaryLabels as {-1, 1} but > CMultilabelLabels define as {0,1...num_classs-1}? What about define > something like

Re: [shogun] About CBinaryLabels and CMultilabelLabels

I suggest: - habe only one class for labels, CLabels, not abstract. -remove all other label classes Internally there might be more distinction, an impl class that is instantiated based on the passed input for example. On Mon, 29 May 2017 at 08:51, Tiramisu Ling wrote: >

Re: [shogun] About CBinaryLabels and CMultilabelLabels

Thank you for your reply! > > > Rather get rid of all classes for labels, offer a single one that > transparently does all the conversions, and checks validity/range. Is that mean we should do the conversions inside CMultilabelLabels? Or we could make CBinaryLabels accept zero as value of label.

Re: [shogun] About CBinaryLabels and CMultilabelLabels

Please no new class! Rather get rid of all classes for labels, offer a single one that transparently does all the conversions, and checks validity/range. Zero sense in my eyes to have multiple classes for labels when we do runtime checks in the algorithms anyways. Also not templates please H On

[shogun] About CBinaryLabels and CMultilabelLabels

Hi, I have a question about the difference between CBinaryLabels and CMultilabelLabels. Why we need to make CBinaryLabels as {-1, 1} but CMultilabelLabels define as {0,1...num_classs-1}? What about define something like 'DigitalLabels' which can accept {-1, 0, 1, ...num_classes}, or just use