CSGObject: all parameters needed in generic base class?

[tklein23]

@karlnapf - talking about CSGObject again, I again suggest pulling out some variables from CSGObject class. Since this state is shared in every object, this seems to be lot more than really needed.

As you worked as well on

• the parameter framework
• the model selection extension

Do you think (a) they are all necessary and (b) do you have an idea how to pull this out? Easy ideas first, we can do this step-by-step. :)

[karlnapf]

Let me try to understand what you are after, currently I am a bit confused. Both parameter and model-selection parameters are bound to classes (which parameters are registered), but in fact also to instances of classes since the TParameter pointers point to the member variable memory.

[tklein23]

I can imaging that you're confused, because model selection and parameter frameworks are two different things.

Let's talk about model selection parameters first: Why do we need maintain data for model selection when, for example, creating labels, io or ui classes? Is it somehow possible to put it to the places where it's actually needed?

[karlnapf]

Its not that different: Both parts allow to register member variables that already exist in memory for accessing them from outside. If you do not register model selection parameters, the list is empty, the overhead is minor, but in fact we could make the container NULL if there is nothing in there to reduce the footprint of CSGObject.

A way to separate things would be to have a separate base class for algorithms or things that are used in algorithms, and then another base class (maybe the Shogun base) for framework parts. But I dont really see the use here. But maybe you know better?

[tklein23]

No new features, but less code, hopefully better tested code of better quality.

Use? None. Sorry to disappoint you. ;)

[tklein23]

About model selection again: Which classes do need the model selection framework and which don't?

[karlnapf]

All classes that register parameters for model-selection need the framework. Look for MS_AVAILABLE in the SG_ADD macro. Not sure where this is going now though

[tklein23]

It's about cleaning up things. Making them maintainable. If things are so tied together as they are right now, then this will bring us pain.

Currently I'm not clear what we can do easily and what we can't do. But I see:

• data classes, like features, vectors, matrices, streaming features, etc. are not using model selection, so why do they have members to do this?
• file reader classes don't use (or don't need) parameter framework or model selection
• SG_ADD takes care about parameter framework and model selection
• etc.

What is it that you're not sure about?

[karlnapf]

Yep I agree,

• data classes (CFeatures)
• algorithm classes (CMachine and more, not so clearly distinct from others)
• helper classes (CMath, file readers, etc)

If those could have base classes for dealing with things as model-selection parameters, this would maybe be a bit cleaner....
In fact, we could in general think about a more clean class hierarchy. Currently, there is lots of wild growing everywhere. Drawing class diagrams might help.

[karlnapf]

This will all be better with tags, once merged