Fergal,

Thanks for the comments, you seem to have a good intuition about how the 
encoder is working.

Just one point about changing radius and its effect on the encoding. I'm almost 
certain (but will have some tests to prove it one way or the other) that the 
SDR is very robust to changes in radius, due to the sparsity of the SDRs.

It depends on how much you change the radius by. If you change it by a large 
amount, it can result in a totally different encoding. But it's correct that if 
you change it by some small amount, the encoding doesn't change very much. 
That's one of the nice properties of this system.

- Chetan

On August 8, 2014 at 10:08:03 AM, Fergal Byrne ([email protected]) 
wrote:

Hi Matt,

Thanks for getting those up in such good order. Well done Chetan, that looks 
even more inventive than the RDSE!

The discussions with Jeff and other Numenta staffers is really intriguing, and 
I think that there are some really important implications for both NuPIC and 
HTM in general from this step forward. I'm writing up my ideas on this and will 
post a link once that's done. A quick teaser:

1. This is a very HTM-compatible idea. You could view each square's "order" as 
a normalised "activation potential" and the process of choosing the top w 
squares as analogous to local inhibition among neurons (with all virtual 
neurons outside the search square forced to zero). So, the square forms a 
"virtual SDR" which is expanded into a full SDR by the fact that it projects 
randomly into the larger bit field of the encoder. 

2. The general "coordinate" paradigm operates on the same principle, in that it 
populates an n-dimensional space with a grid of hash-based (pseudorandom) 
"signature neurons" which can be sampled using this local inhibition scheme to 
derive a location fingerprint algorithm. This seems to me to be a genuine 
invention in the field of high-performance semantic encoding of 
high-dimensional spatial position (which is either treated as a total mystery 
or abstracted away using fragile tricks).

3. It is clear how you could combine this encoding scheme with data which 
varies by location, to create a richer idea of "order" in feeding the SDR 
generation algorithm. For example, you could combine random "order" with 
altitude or temperature data to choose the top w squares. 

4. This is a wonderful model for how we "zoom in" or "zoom out" and perceive a 
continuously but smoothly varying model of the world. It also models how we can 
perceive gracefully degrading levels of detail depending on how much time or 
attention we pay for a perception. In this case, the "encoder" detailed here 
would be a subcortical structure or a thalamus-gated (attention controlled) 
input or relay between regions.  

5. This method solves the presentation-order dependence issue of the original 
RDSE, where the encoding of a value depends on which values were presented 
before it, unless you precalculated values from an initial "centre" (which 
could have significant memory or compute costs). The coordinate encoder has a 
deterministic, O(1), order-independent algorithm for computing both "order" and 
bit choice. The only issue I see is that the pseudorandom number is 
Python-specific, and so a C++ encoder (or a Java/Clojure encoder) will likely 
produce completely different answers (but see next point).

6. I believe it would be worth exploring using Perlin noise (or some similar 
cross-platform pseudorandom generator) to generate the order and bit choice 
values. This would give you a) identical encodings across platforms, b) 
pseudorandom, uncorrelated values when the noise samples are far enough apart 
(eg when the inputs are integers as in this case), and c) smoothly changing 
values if you use very small step sizes.

Just one point about changing radius and its effect on the encoding. I'm almost 
certain (but will have some tests to prove it one way or the other) that the 
SDR is very robust to changes in radius, due to the sparsity of the SDRs. In 
other words, the overlap in an SDR at radius r with that at radius r' (at the 
same GPS position) will be high, because you are only adding or removing an 
annulus around the same position (this will be similar to adding or removing a 
strip of squares when a small position change occurs).

Regards,

Fergal Byrne


On Fri, Aug 8, 2014 at 2:52 AM, Matthew Taylor <[email protected]> wrote:
In this video, Numenta engineer Chetan Surpur explains NuPIC's
Geospatial Coordinate Encoder, which is used to generate predictions
and anomaly indications from temporal geospatial data (like you get
from GPS).

https://www.youtube.com/watch?v=KxxHo-FtKRo

This video describes the NuPIC Geospatial Tracking application and
shows how it can be used to analyze GPS data.

https://www.youtube.com/watch?v=M4dD9wCQLkA
---------
Matt Taylor
OS Community Flag-Bearer
Numenta

_______________________________________________
nupic mailing list
[email protected]
http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org



--

Fergal Byrne, Brenter IT

Author, Real Machine Intelligence with Clortex and NuPIC 
https://leanpub.com/realsmartmachines

Speaking on Clortex and HTM/CLA at euroClojure Krakow, June 2014: 
http://euroclojure.com/2014/
and at LambdaJam Chicago, July 2014: http://www.lambdajam.com

http://inbits.com - Better Living through Thoughtful Technology
http://ie.linkedin.com/in/fergbyrne/ - https://github.com/fergalbyrne

e:[email protected] t:+353 83 4214179
Join the quest for Machine Intelligence at http://numenta.org
Formerly of Adnet [email protected] http://www.adnet.ie
_______________________________________________  
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