Chetan, That is very interesting news! I would be happy to lend a hand with testing that - right now I'm porting the spatial pooler (done with the new TM and unit and integration tests). Maybe I can look into it if nobody has by then?
Fergal - that is awesome! I can't wait to read it! Maybe we should start a new thread for comments? Something like, "Trashing Fergal's new post on the Geospatial Encoder!" :-) Just kidding! I always enjoy the particular way you express yourself when you talk about this stuff - I always learn something. I look forward to reading it. Cheers, David Sent from my iPhone > On Aug 14, 2014, at 4:59 AM, Fergal Byrne <[email protected]> wrote: > > 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
