search

numenta / htmresearch

Experimental algorithms. Unsupported.
GNU Affero General Public License v3.0
223 stars 109 forks source link

classification_network.py assumes classifier has HTM-specific inputs/outputs #272

Closed BoltzmannBrain closed 9 years ago

BoltzmannBrain commented 9 years ago

The sequence classification network factory assumes the classifier region has inputs/outputs for predictedActiveCells, which is not always true -- e.g. KNNClassifier. This is a problem here. An if statement checking for the region type would work, but I suggest we move region-linking logic to the specific createXRegion() methods. Thoughts @marionleborgne @scottpurdy?

This is currently breaking the nupic.fluent HTM classification model -- test here.

marionleborgne commented 9 years ago

@scottpurdy suggested last week that we moved the logic of combining the TM states (predictedActive, activeCells) outside of the classifier region, in its own custom region before the classifier. That way, the classifier (KNN / CLA) will always take bottomUpOut and categoryOut as an input. And we don't have to link other inputs depending on the classifier type (KNN/CLA/other).

So we can remove this and this for now.

However, I agree with moving the linking logic with to the specific createXregion. As a next step in the classification experiment for the sensor data, I will compare the classification accuracies of various configurations for the network (see below) so we need to be able to link them accordingly, depending on wether or not a specific region was created.

marionleborgne commented 9 years ago

Submitted a PR that should fix this problem. https://github.com/numenta/nupic.research/pull/273. No need to feed the preductedActiveCells to the classifier now. Then as you said, we should move the linking logic in createXregion. So that we can have different network configurations (Sensor -> SP -> TM -> CLA, Sensor -> SP -> TM -> UP -> CLA, etc... ) to perform the tests.

Let me know if that works for you.

cogmission commented 9 years ago

Sorry to submit unsolicited opinions, but I'm going to anyway... :-)

This is just a suggestion, but wouldn't it be ideal to:

  1. Not have type-specific Regions
  2. Have regions be able to "house" any algorithm
  3. Have special "Transformers" that can: A) Transform the type of output of a given algorithm to a general form then; B) Transform a given input to the compute() method signature required for the next algorithm in the chain?

This way you can begin to look at ways to unify the inputs/outputs into common types and you have a Network that can be composed of any Region containing any algorithm type (currently existing or unknown future type) ?

I know it doesn't do much good to suggest deep architectural shifts in the middle of project completion - but these kinds of shifts can happen over time if chosen to be a goal.

This is how HTM.java's Network is composed, so I know it can work... ...and its much less expensive to write a data transformer than to create entire Regions of a given type - plus you don't wind up with Type Explosion which can significantly pollute a code base.

Just a thought...

On Sun, Aug 16, 2015 at 11:36 AM, Marion Le Borgne <notifications@github.com

wrote:

Submitted a PR that should fix this problem. #273 https://github.com/numenta/nupic.research/pull/273. No need to feed the preductedActiveCells to the classifier now. Then as you said, we should move the linking logic in createXregion. So that we can have different network configurations (Sensor -> SP -> TM -> CLA, Sensor -> SP -> TM -> UP -> CLA, etc... ) to perform the tests

— Reply to this email directly or view it on GitHub https://github.com/numenta/nupic.research/issues/272#issuecomment-131579629 .

With kind regards,

David Ray Java Solutions Architect

Cortical.io http://cortical.io/ Sponsor of: HTM.java https://github.com/numenta/htm.java

d.ray@cortical.io http://cortical.io

BoltzmannBrain commented 9 years ago

@marionleborgne yes this plan works for me; I made a followup issue (#274). The next step in the nupic.fluent experiments is to implement a Sensor -> UP -> classifier network, so this should help.

BoltzmannBrain commented 9 years ago

@cogmission thank you for the ideas, although it's unclear to me if these changes are advantageous. And yes you are correct, these changes are big overhauls of the network architecture that would definitely slow down our research progress.

marionleborgne commented 9 years ago

@BoltzmannBrain re: #274 - awesome. This fits great with the next steps for both Sensor data and NLP classification experiments.

cogmission commented 9 years ago

@BoltzmannBrain The main advantage I see is that you would have a Single type called "Region" which you could plop any algorithm into. Special handling for input/output data would be handled by transformation functions. I'm very sure (at least it worked out this way for HTM.java) that in the end you would have far fewer transformation functions than types of Regions, if done the other way. This would definitely aid research/experimentation/prototyping because you could just plop whatever algorithm into a given Region.

I definitely appreciate wanting to keep your eye on the "big picture" and forward the progress of research (its most important effort) - but its something to keep in mind if the chance to overhaul things comes along? :-)