Hi, I think the main interface (Instance) is very complex. It has a very large number of methods, and the reason behind some of them, and how they relate to each other, is obscure to me.
For example, what is classAttribute supposed to do when we have a multi-target instance? What about sparse-only methods when called on dense instances? What is the semantic of insertAttributeAt and how is it different from setValue? I have other doubts, but maybe it's just lack of documentation/comments in the code. In general, what about having a hierarchy of interfaces for Instances, rather than putting all the functionality in a single one? Cheers, -- Gianmarco On 20 January 2015 at 10:47, Matthieu Morel <[email protected]> wrote: > I'm confused. From what I see the number of classes is currently fixed > in the instance header. As if it was static. I suppose you can work > around that limitation with some hacks but I want to use a clean API > for that. > > Or is there a recommended way I'm missing? > > Thanks, > > Matthieu > > On Tue, Jan 20, 2015 at 7:17 AM, Albert Bifet <[email protected]> > wrote: > > Olivier, you're right, that was also possible in the old implementation. > > > > Cheers, > > Albert > > > > On Tue, Jan 20, 2015 at 1:45 PM, Olivier Van Laere > > <[email protected]> wrote: > >> Hey, > >> > >>> One thing I want for example, is to dynamically set the number of > >>> classes for an instance, as we discover those classes in the stream. > >>> Hopefully the new instances will allow that. > >> > >> Out of interest: how was this not possible in the old version? Did the > instances themselves store info about the number of classes? I’m asking as > I remember having dynamic expansion of the potential class labels in the > Naive Bayes model, but there it is the model that keeps track of which > labels have been seen so far, by reading that data out of the instances. > >> > >> Thanks for the update Albert, seems an interesting improvement over the > current implementation. > >> > >> Cheers, > >> Olivier >
