NuPIC Topology Notes

As I investigate topology in NuPIC’s spatial pooler, I’m keeping my notes in this wiki. More info will be added over time. If you have any suggestions or answers to my questions, please post them below.

Open Questions:

  1. What is a good rule for column dimensions? For example, I have a 32x32 bit input. What dimension should my columns be? I also have input that is not square, like 20x30. I am assuming that if the input encoding has topology, the column output from the SP will also have topology, but does it have to?

Things With Which to Experiment

  • local inhibition radius
  • number of active columns per inhibition area
  • column dimensions vs input dimensions
1 Like

No in my experience. The Column dimensions 32x32 will translate int 1024 columns and is “interacted” with as if it’s a 1-Dimensional flat array with a width of 1024 instead of 32 columns by 32 rows.

1 Like

That leads to the assumption that the topological output of the SP exists simply to pass topology upwards to other layers in the hierarchy then.

1 Like

Turns out this is not true. When I tried to submit a 1D column dimension that was the input length * width, I got this failure during SP initialization:

InvalidSPParamValueError: Input dimensions must match column dimensions

I can’t really comment on the “intent” of the algorithmic design? :wink: That’s a little bit above my pay grade for the time being :stuck_out_tongue: But – I seem to recall that when I first came around, topology hadn’t even been added to the SP, and was done after that point… iirc

I believe that is (or was) a configuration check only. Internally, the SP (at least at one time), treated the input array as 1 Dimensional. So forgive me if my knowledge is a bit outdated…

As a bonus mention, the Layer code in HTM.Java, automatically configures the column dimensions in order to avoid having to have the user configure this parameter on every input. see here

I recommended @scott add this to NuPIC…?, what it does is auto configure it if the user “forgets” to input the correct input dimensions.

Only for global inhibition, AFAIK. In this case, the local inhibition calculation takes dimensionality of the input vector into account when deciding how to inhibit columns:

The _getNeighborsND documentation:

Since the permanence values are stored in such a way that information about topology is lost. This method allows for reconstructing the topology of the inputs, which are flattened to one array. Given a column’s index, its neighbors are defined as those columns that are ‘radius’ indices away from it in each dimension. The method returns a list of the flat indices of these columns.

1 Like

Right. So is there another case where column dimensions are taken into account? I’m being lazy in asking because I’m knee-deep in TM code at the moment, and I’m operating off of my memory of SP from a while ago?

Hey, sorry @rhyolight - you’re asking for precise answers and I’m only giving you conversational ruminations based on loose memory… I shouldn’t have chimed in because I don’t have the time right now to investigate this with precision. My apologies… :wink:

Also are there any other example scenarios besides vision where topology
would be called for? I know that data containing topological associations
in the encoding space does it, but I’m just trying to get a sense of what
that really means in practice/ what it would apply to. Wouldn’t it just be
any time the different areas of the encoding space depended on each other,
such as having multiple interdependent input fields? If anyone has any
basic ideas or links to resources I’m super interested in this. Thanks!

1 Like

Like @ycui said in this post, it could be used for somatic sensory input (touch). Also heat, pressure, things like that that are measured across a physical space.