Unifying the columns/cells into a single entity

[cogmission]

@rhyolight

This was proposed over a year ago and we voted it down, so we should not consider this option.

David Ragazzi proposed using an over-arching OO approach to all constructs. That was a super set of what I’m talking about. Whether they’re columns and cells, and are 00 or mapped primitive integers - their state is still spread between the algorithms. The discrete part of pulling out and Unifying the columns/cells into a single entity was never voted on. You guys agreed with my idea of pulling the Connections out into a separate data structure, why not this?

This specific issue is pulling out boosting and/or inhibition into separate code modules/object/algorithms? The reason my idea of isolating columns/cells is pertinent to this is because if you isolate the boost/inhibit functionality they still will be acting on the columns/cells which means they cannot be used independently of an instance of SP or TM. This is very prohibitive/tight coupling.

[rhyolight]

Here is where we left this conversation:

@rhyolight

Subutai, thanks for responding. This situation is a bit touchy. I
don’t want to discourage any community proposals, but Subutai and
Scott are bringing up valid points, and we can’t have this discussion
forever.

On Mon, May 11, 2015 at 1:11 PM, Subutai Ahmad wrote:

As a way of moving forward let me suggest that we continue expanding the
generic Connections data structure with the goal of transitioning the
spatial pooler class to this structure. We are all in agreement with that
step.

Yes, let’s move forward with this. Is there an issue in GitHub for it?
If not, someone who understands the problem should create one.

After that let’s all look at a concrete working proposal such as a
real working Region (not pseudocode) that proves to us how things become
simpler. This could go in the community.research repo. If it really does
eliminate a lot of code and makes things easier to understand, I’m all for
it.

100% agreed. It is going to be hard to resolve this discussion through
emails and theoretics. Some concrete code would be a great way to
prove a better structure. Code wins arguments. But let’s be sure and
work on the SP first so we’ll be in a better place to continue this.

But no one created an issue, so this did not move forward.