Hi guys, My post on the Geospatial Encoder is now up at http://inbits.com/2014/08/implications-of-the-geospatial-encoder
Comments welcome here on the mailing list (most comments on my blog are about fake luxury branded ladies' bags). Regards Fergal Byrne On Tue, Aug 12, 2014 at 1:43 AM, Chetan Surpur <[email protected]> wrote: > David, > > Yes, the Coordinate Encoder with # of dimensions = 1 essentially performs > the same task as the RDSE, with the advantage that you can pick the > resolution (via the radius) dynamically. With it, you would be able to > encode any scalar value, without having to generate buckets beforehand. > > I think it would be worth testing this out and comparing against the RDSE, > with the eventual goal of replacing it with a Coordinate Encoder. > > - Chetan > > On August 11, 2014 at 1:58:55 AM, cogmission1 . ( > [email protected]) wrote: > > This also parallels the adjustment of our attention as the applicable > bounds of perceptions change with increasing acceleration. For instance, > when we are playing a race driving game and our speed accelerates, our > attention is adjusted to always be further out or further down the road > because paying attention to finer grained distances in front of us becomes > less and less fruitful (and difficult) - so our attention becomes spaced > down the road further. We are able to "adjust" the context of our attention > to suit time spans and intervals which are appropriate to a given > circumstance (or rate of input). > > @Fergal or @Anybody - I wonder if the comparison between the type of data > traversal typical with the RDSE and that of the GOSE (<-- phonetic > acronyms, I love em) is identical? Mind you, I just encountered the RDSE > video a couple of days ago so I haven't spent much time contemplating it. > But as far as I recall, the RDSE is an attempt to encode values regardless > of order and scale, so buckets are formed (given a particular resolution or > "range" really) relative to each other. Whereas the GOSE has an advantage > in that the "world" is divided equally into identically sized squares > implying that the range is "fixed" in comparison to the types of data that > the RDSE has to account for? In other words there are no outliers or range > or scale changes and each square has an assigned unique index also? I'm > just wondering if the encoding scheme can be applied equilaterally to > scalars that are unknown? > > Also, I'm doing a port of NuPIC to Java (CoPIC-J temporary name until Matt > gets back from vacation) https://github.com/cogmission/copic-j - and I > find the differences in pseudorandom number generation to be a slight > annoyance (as my main requirement is identical unit/integration test > results). Fergal, I think your idea of investigating a cross-platform > random number solution is ideal especially as implementation of NuPIC in > different languages becomes more and more prevalent. Probably better to > saddle that horse early on? > > David > > > > > > On Sun, Aug 10, 2014 at 8:26 PM, Chetan Surpur <[email protected]> > wrote: > >> 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 >> >> > _______________________________________________ > 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 > > -- 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
