Still concerning the pass-through encoder:
At various occasions I have noticed that the "pass through" functionality 
corresponds to skipping the spacial pooler.
In my current understanding this would not be correct.
It is true that the output of the spatial pooler is in SDR format. But it 
cannot be implied from there that the the spacial pooler actually SDRizes the 
input.
If an SDR is feed in the SP that (randomly) subsamples it, the resulting output 
will still be a valid SDR (through the noise resistance property of the initial 
SDR).
If a non SDR bit pattern is subsampled the result will be looking like an SDR 
while having lost the semantic context of the input data (lacking the NR 
property.

Another problem that I have on the conceptual level, when assuming that SDR 
data doesn't need the SP stage is that in a hierarchy of layers the output data 
of every layer would have the SDR format. If it  would be fed into the next 
higher level, one could skip the SP in all subsequent higher levels , leaving 
the question why there is an SP at all.

Pleas forgive me if I'm still missing some fundamentals, I am trying hard to 
catch up ;-)

Francisco

On 07.08.2013, at 00:43, Marek Otahal wrote:

> +1 for the identity/pass-thru encoder. Also, check the temporal pooler code, 
> as you could skip the spatial pooler and feed directly to TP, I remember some 
> discussion about this and think it has been implemented.
> 
> 
> On Tue, Aug 6, 2013 at 11:49 PM, Francisco Webber <[email protected]> wrote:
> Scott,
> I heavily support this idea of a pass-through encoder as thats what my 
> text-SDRs will probably need.
> 
> Francisco
> 
> On 06.08.2013, at 22:49, Scott Purdy wrote:
> 
> > One thing we have talked about but not implemented is a pass-through 
> > encoder.  It would let you create an SDR in any way you want and pass it in 
> > to the CLA model's compute method as the field value.  That would probably 
> > be the best way to approach your problem if you want to implement it with 
> > the CLA.
> >
> >
> 
> 
> _______________________________________________
> nupic mailing list
> [email protected]
> http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
> 
> 
> 
> -- 
> Marek Otahal :o)
> _______________________________________________
> 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

Reply via email to