Use k-d tree to optimize performance in visual function

[TimoSci]

The visual function, which finds the winner neuron for an arbitrary "specimen" input, was using a brute force search to find the nearest neighbor among the neuron codes.

A k-d tree search is usually faster than a brute force search, especially when doing a large number of queries over a large number of neurons.

The disadvantage of a k-d tree is that the initial construction of the tree is costly, but once constructed, search queries are fast. That's why we can't use the k-d tree in the training algorithm - we would have to reconstruct after every step.

But for functions on an already-trained SOM, like mapToSOM, a k-d tree can be advantageous, in most practical use cases.

Example of a benchmark I have done

I have included an optimized version of the visual function. The old function is renamed visualGeneric because it uses multiple dispatch in findWinner to decide which search algorithm to choose.

A test is also included, to test whether visual and visualGeneric return the same result.

PS. Caching the k-d tree in the SOM struct might also be a good idea.

[andreasdominik]

Indeed - its a good idea to optimise the NN search ( I ignored it because even the brute force search is not time limiting for SOMs with some 100s or 1000s neurons).
However, I'll do some tests and include it in the next release.
(nearestNeighbour.jl is actively maintained; the addtl. dependency should be no disadvantage).