Better documentation for Coordinate encoder - radius and SDRs

[breznak]

Q1: I'd like to know better documentation of radius param in CoordinateEncoder, https://github.com/numenta/nupic/blob/master/nupic/encoders/coordinate.py#L104 esp. its relation to "similarity/overlap" and performance, see

One case where the cache would not be good for the CoordinateEncoder is when it is set up to have fine-grained resolution with a large radius. In these cases, the input coordinates may very rarely match exactly and the large radius ensures that the encodings still have overlap for similar, but not exact, coordinates. In this case the caching mechanism would just slow the function down. I don't know if normal use cases would have high cache hit rates or not but perhaps @chetan51 has an intuition for it?

from https://github.com/numenta/nupic/pull/2501#issuecomment-136948362

Q2: The other thing is its "SDR" output - what is the quality of such a SDR? The theory says it's possible to merge SDRs to obtain a "semantic union" of them. When I asked this on the ML, I was advised this may not work. So is the output of coordinate supposed to go directly to a temporal memory, or it needs to pass through a SP (to create a better quality SDR)? (for what sizes of w,n,radius?)

EDIT: Q3: (If answer to Q2 is "use SP", maybe even if not:) What is the advantage of using a coordinate encoder instead of a MultiEncoder with scalars (and then SP)?

[breznak]

CC @rhyolight @chetan51

[chetan51]

Details on how the encoder works: https://www.youtube.com/watch?v=KxxHo-FtKRo

Watching and understanding this video might help you answer those questions.