KNearestNeighbor should not assume zero-based consecutive class labels

[GoogleCodeExporter]

KNearestNeighbor should not assume zero-based consecutive class labels. If the 
labels (the outputs parameter of the constructor) happens to be something like 
{4, 2, 5} (does not have zero and does not include all labels from 0 - 5), the 
method Compute crashes.

Attached is a modified version of the class that works with this use case 
without the problem.

Original issue reported on code.google.com by Thanacha...@gmail.com on 2 Nov 2012 at 12:14

Attachments:

• KNearestNeighbor.cs

[GoogleCodeExporter]

Many thanks for the feedback and the patch. However, most methods in the 
framework are made to work with zero-based class indices by design (they are 
treated as indices, after all). The issue I see with the Nearest Neighbor class 
is due to its constructor. I should have added a constructor with a classCount 
parameter instead of relying on counting distinct instances from an output 
label vector. My bad.

Do you think this would help solving the problem?

Original comment by cesarso...@gmail.com on 2 Nov 2012 at 2:36

• Changed state: Accepted

[GoogleCodeExporter]

If that is the case, we can just take the max of all the class labels, add one 
to it, and the result is the classCount we need...

Original comment by Thanacha...@gmail.com on 2 Nov 2012 at 2:51

[GoogleCodeExporter]

Fixed on Accord.NET 2.8.

Original comment by cesarso...@gmail.com on 6 Nov 2012 at 5:23

• Changed state: Fixed