The idea is to ditch separate code for SP, and use just the TM.
In reality, bioligically the two processes (SP, TM) are not separate.
In code, TM uses Connections class; SP has the logic in itself. SP works as TM that has only 1 cell per column (no high-order memory).
WAYs to do it:
- A) instead of SP, call TM(with 1 cellPerCol)
- will need to implement inhibition.
- B) keep SP code, just also use Connections as the backend
- code cleanup
- more biological
- possible better optimizations
- is Connections already too complicated?
What do you think?
@breznak That might work. You can build such a module and see if it works. If it does you can add it to the library (in addition to what is there). That is what the framework is for.
Yeah, I also think it might. But I’d love to hear more experiences if it’s a good/bad way to go…time’s short and there’s so much to do now.
to a big surprise I found that
ConnectionsPerformanceTest contains parts that do just as intended here: implement SP functionality with Connections backend.
@rhyolight @mrcslws @chetan51 could you please shed some light on the history? Is there a reason why you didn’t pull the idea to the end? How was the performance? Seems the code is very nice and clean using the Connections! (y) How is the python version in this regard?
I had similar idea as to the implementation of SP and TM. But I had arrived at the same conclusion by thinking backwards that every TM columnar layer is essentially an SP and only a single SP unit(minicolumn) will be selected from the TM column as active after selecting winning “cells”.
@abshej So why is this not used? Functionally it fits, so my question is why not? The performance?
I can’t say about the performance since I haven’t started with the implementation to this detail.
I don’t know anything about this, and Chetan has moved on to other projects. Maybe @mrcslws can help.
Btw, this task, SP on Connections is implemented in nupic.cpp repo.