Thoughts on synblast

[clbarnes]

Rather than having 2 trees for input and output synapses, or a binary axis on the lookup table for "same" and "different" types for the nearest match, we could go more like NBLAST and give each point an attribute describing its neighbourhood, as the exact point match isn't that informative in dense regions with approximate nearest neighbours. This will need some tweaking, but it would be something like:

• For each point in the cloud, find its k nearest neighbours
• Score the point on how output-y its neighbourhood is (e.g. if 0 is outgoing and 1 is incoming, then 0.1 would be a synapse in a region where most of the synapses are outgoing)
  • This should be weighted by distance, although you then need to figure out how to weight the 0 distance (I'd propose some proportion of the next shortest distance)

When querying point matches, you'd do 1 - abs(q_neighbourhood - t_neighbourhood); i.e. if they had identical neighbourhoods, you'd have 1 (just like distdots) and if one was entirely output and the other entirely input, you'd have 0.

I have an implementation for this, although I haven't hooked it in to the smat training structure to test it yet.

[schlegelp]

Oh interesting. I have FlyWire matches for ~2800 hemibrain types which gives a decently sized test set.