Improve handling of "k"
MZ just added getK() and setK() to the kNN model. This brings up some interesting issues:
- I can't think of a case where k == 2 is better than k == 1. Disallow it?
- Ties go to the first class found. Find a better metric? Distance? Average distance?
- If setK() asks for a k that is greater than the current number of neighbours, then k is set to the number of neighbours. Maybe kNN should remember the number that the user requested so that k can be increased if new neighbours are added?
- Using getK() and setK() in a modelSet required casting a baseModel* down the inheritance chain. Is this bad design? How will this work if more parameters are exposed in more models?
This issue should probably be broken up into sub-issues.