Thanks for raising these issues. I understand how that could be confusing and part of it is why we have separated the FlatSpatialPooler from the more general SpatialPooler class.
Hopefully Subutai can chime in since he understands high tier much better than me but here are my suspicions for the behavior: 1. The FlatSpatialPooler implementation includes high tier which causes it to try to memorize the initial patterns it sees. It will try to uniquely represent the initial patterns. Since the first set of columns hasn't had time to adjust to connect to all of the active bits in its potential pool, there is an opportunity for other columns with high initial boost (part of high tier) to win instead. This is my suspicion but not 100% sure. High tier solves some problems but causes others. When we were designing the new SP implementations we had an explicit goal of separating it from the general SpatialPooler class. 2. The FlatSpatialPooler has an optimized path for no topology. This could result in a noticeable difference in speed, even when you specify no topology in the SpatialPooler. We could have included the optimization in the regular SpatialPooler class but decided that special-casing made more sense in a subclass. We wanted to keep the code really simple and clean in the generic version. On Sun, Feb 23, 2014 at 11:28 PM, Kevin Martin <[email protected]>wrote: > <https://github.com/lonesword/nupichelloworld/blob/master/helloworld.py> > Tinkering a bit, I came to notice that if I used the SpatialPooler class > instead of FlatSpatialPooler, I get the same set of active columns for the > same input. But it takes much longer to get the results and the 'busy' > light of my computer stays on for a really long time. From what I read, I > had assumed that the only real difference between the normal spatial pooler > and the flat spatial pooler was the lack of topology. But since both of > them returned different results I think FSP is minimalistic in much more > ways (the SP returns the expected result, while the FSP returns a new > result for the same input vector which was not what I had expected). But > I'd still like to know why the Flat SP returned different set of active > columns for the same input. > > On Sun, Feb 23, 2014 at 11:19 AM, Kevin Martin < > [email protected]> wrote: > >> I'm on my way to writing a 'hello world' equivalent for nupic. I decided >> to work with a flat spatial pooler since it has no topology. I was able to >> send in an input vector and get the list of active columns. The source code >> is hosted here : >> >> https://github.com/lonesword/nupichelloworld/blob/master/helloworld.py >> >> I was under the assumption that similar inputs to the spatial pooler >> results in similar SDRs. That is, if I give the same input twice, it is >> expected to produce the same SDRs. >> >> However, sending the same input vector to the compute() function returns >> a different set of active columns every time. I'm pasting the code snippet >> here : >> >> for i in range(10): >> example.flat.compute(testinput,True,active) >> for i in range(4096): >> if active[i]!=0: >> print i, >> print " " >> active[0:]=0 >> >> flat is an object of FlatSpatialPooler, >> testinput is the input array, >> active is the active list of columns. >> >> I got a different set of active columns for each iteration. Why is this >> so? I'm feeding the pooler the same input vector each time. >> > > > _______________________________________________ > nupic mailing list > [email protected] > http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org > >
_______________________________________________ nupic mailing list [email protected] http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
