Hey Kevin, Thanks so much for taking this task on. I like the direction this tutorial is going. Once complete, we should be able to create a nice reference document to describe it. You should take a look at our python coding conventions[1], as we'll need to make sure all code within nupic adheres to the same standard. I'd eventually like to get your tutorial into the nupic repo, so reviewing the python style guide and running pylint now will probably save you some trouble later. :)
[1] https://github.com/numenta/nupic/wiki/Python-Style-Guide --------- Matt Taylor OS Community Flag-Bearer Numenta On Mon, Feb 24, 2014 at 2:35 PM, Subutai Ahmad <[email protected]> wrote: > > It is great to see this taking shape. I've left comments in the issue that > is tracking this work: > > https://github.com/numenta/nupic/issues/654 > > Note that we are actually in the process of removing FlatSpatialPooler (see > https://github.com/numenta/nupic/issues/627). The high tier stuff was a hack > for tiny datasets, and we don't seem to need it anymore. > > --Subutai > > > On Mon, Feb 24, 2014 at 11:05 AM, Scott Purdy <[email protected]> wrote: >> >> 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: >>> >>> 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 >> > > > _______________________________________________ > 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
