What type of neighborhood does the topographic error consider?

[SandroMartens]

So a topographic error occurs when the two bmu of a sample are not adjacent. Shouldn't then t = 1? If the bmu are two hops apart in a corner, their euclidean distance is sqrt(2) = 1.4142 . So with distance > 1.42 this doesn't count as an error.
Or am I missing something?

[matthew-balogh]

I've just ran into the same issue. Is this intentional, @JustGlowing? If so, is it consistent with the neighbourhood update process? If not, then topographic_error() may give a biased state of the som prototype.

[JustGlowing]

Can you please give an example of where the unexpected behaviour happens and what you think the correct outcome should be?

[matthew-balogh]

In a lattice with a rectangular topology, a node has four neighbors. When calculating the topographic error, the positions of the first and second best-matching units shall be compared with respect to this grid. However, _topographic_error_rectangular() uses a threshold t = 1.42. This will accept nodes that meet at their corners while being unconnected (Manhattan distance = 2) as neighboring ones.

I extended your test_topographic_error by adding a new weight of [50.0] at position (3, 3) as described and depicted below. This node touches the node at position (4, 4) with the weight of [15.0], but they are not neighbors according to the topology. The expected behaviour is that the topographic error of the sample [49] would be 1. Yet this unit test fails.

def test_topographic_error(self):
    # 5 will have bmu_1 in (2,3) and bmu_2 in (2, 4)
    # which are in the same neighborhood
    self.som._weights[2, 4] = 6.0
    # 15 will have bmu_1 in (4, 4) and bmu_2 in (0, 0)
    # which are not in the same neighborhood
    self.som._weights[4, 4] = 15.0
    self.som._weights[0, 0] = 14.0
    # 49 will have bmu_1 in (3, 3) and bmu_2 in (4, 4)
    # which meet at their corner yet are not direct neighbors
    self.som._weights[3, 3] = 50.0
    assert self.som.topographic_error([[5]]) == 0.0
    assert self.som.topographic_error([[15]]) == 1.0
    assert self.som.topographic_error([[49]]) == 1.0

4 [ 0.0] [ 0.0] [ 0.0] [ 0.0] [15.0]
3 [ 0.0] [ 0.0] [ 0.0] [50.0] [ 0.0]
2 [ 0.0] [ 0.0] [ 0.0] [ 5.0] [ 6.0]
1 [ 0.0] [ 2.0] [ 0.0] [ 0.0] [ 0.0]
0 [14.0] [ 0.0] [ 0.0] [ 0.0] [ 0.0]
     0      1      2      3      4

As @SandroMartens pointed out, the threshold shall be t = 1, shouldn't it?

[JustGlowing]

Thanks for your example, I finally understand this!

This is an intended behaviour of the implementation as it considers a neighborhood of 8 cells (Moore) rather than 4 (Von Neumann). If you have a use case I could add an option to select the neighborhood type.

[matthew-balogh]

I see, thank you for the clarification!

I had this thought that if only the direct neighbors were pulled (Von Neumann) along with the best-matching unit during update, then those additional 4 nodes in the corners of the neighborhood would be left behind by the algorithm. Evaluating the quality of the SOM by topographic error based on the Moore approach then could be inconsistent.

But I see the default neighborhood function is Gaussian which will reach those nodes as well to update, am I correct?

[JustGlowing]

Yes, that is correct. Also, I don't want to make this too complicated.

Btw, I've checked https://github.com/matthew-balogh/lilypond, such a good idea!

[matthew-balogh]

I have been using your MiniSom implementation to experiment with Self-Organizing Maps for a while now as part of my Master's studies in Data Science, and my project lilypond builds upon it.

I appreciate your take on it, thanks for letting me know!