avoid kernels in NCC

[Peter]

NCC has no constructor taking KernelLookup?& (or DataLookup2D&). Good. However, make_classifier is taking a Datalookup2D (and must do so due to SupervisedClassifier? interface). Even worse, present design allows EnsembleBuilder? to be built from an NCC and a SubsetGenerator? containing KerneLookups?. The similar is true for SVM demanding the user knows which classifier goes with which DataLookup?. Not optimal.

Suggestion:

EnsembleBuilder? constructor takes a Sampler instead of SubsetGenerator?. Internally, EnsembleBuilder? creates a SubsetGenerator? from the Sampler and from the data of the mother. This implies SupervisedClassifer? must have a pure virtual function

const DataLookup2D& data(void) const=0

This change would make it impossible to try to train an ensemble with incorrect type of data. Only data supported bu constructor interface would be possible to use in ensemble.

[Markus Ringnér]

Given how we use EnsembleBuilder? at the moment this is a good idea. Will it cause problems in a future where EnsembleBuilders? consist of a mixture of classifier types? Probably not because mixing classifiers that use kernels with classifiers that use matrices will be problematic anyway. I guess if an ensemble with both SVMs and NCCs is to be supported it will have to be based on MatrixLookups? and use SVM functions accepting MatrixLookups??

[Jari Häkkinen]

Removing type "idea" and changing this to a "request".

[Markus Ringnér]

Going through this four months later I end up with:

Following the suggestion part of the description is feasible and should be done.

However, this still leaves us with a make_classifier that takes a DataLookup?. For the polymorphism to work this is the way it has to be. Is this the way this ticket was inteded to be resolved Peter (Jari) ?

[Peter]

Yes. make_classifier should take a DataLookup, which should not be a problem since only the advanced user would think of using that function (make_classifier).

[Markus Ringnér]

(In [722]) Closes #129