Yes, thanks Chetan. As Fergal points out, the number of active squares in common to two different size boxes at roughly the same location will on average be the ratio of the areas of the two boxes--so that as he says "the overlap goes down gracefully at matching speeds". This is graceful with respect to area, however. Under the assumption that the size of the boxes is proportional to the speed of the objects(is this correct?), then for some reasonable speeds, the ratio of the areas will be quadratic in the ratio of speeds. And if you're encoding three spatial dimensions then the ratio of volumes might be cubic in the ratio of speeds. This can make for a more drastic decrease in overlap when speeds differ. In particular overlap is not related to closeness in a simple way for objects of different speeds.
When there are few active squares and the ratio of size of the boxes is large, so that the expected overlap is in the small numbers, statistical fluctuations can make this especially significant. Five to one is a fair approximation of the difference in speed between a Piper Cub and a 787, and for instance if there were 25 active squares, and assuming that the active squares are uniformly spread out, the chance of having zero overlap is more than 36% (the binomial distribution <http://en.wikipedia.org/wiki/Binomial_distribution> with n=25, p=1/25 and k=0, if anyone is interested). The C4OE folks have an interest in mapping air transportation anomalies with their data set, and are implementing NuPIC with this goal in mind. Near collisions are an interesting anomaly for them, and it looks like some interesting cases could be invisible to them if parameters are not chosen carefully. Can you point me toward the part of the geocoder in which this is implemented, so I can get a better sense of how this works? thanks, Tom On Mon, Jan 12, 2015 at 11:56 AM, Chetan Surpur <[email protected]> wrote: > Hi Tom, > > It sounds like your understanding is correct. The only part of your email > I didn't understand was this: > > > On the other hand, if I'm walking down the middle of the street you're > going to be uncomfortably close, but the geospatial encoder won't register > this. > > Can you elaborate on that? > > - Chetan > > On January 11, 2015 at 9:24:00 PM, thomas taylor ([email protected]) > wrote: > > After a few days delay, I'm bringing this to the nupic list from the nupic > theory list, as suggested by Matt Taylor. > ********************************************* > Message: 1 > Date: Tue, 6 Jan 2015 12:53:07 -0700 > From: thomas taylor <[email protected]> > To: [email protected] > Subject: a geocoder feature? > Message-ID: > <CAGnmPQr0p85tzoHivoSfR= > [email protected]> > Content-Type: text/plain; charset="utf-8" > > Hi all, If this belongs on another list please point me in the right > direction. I've been asked by the Cameron Hunt at the Center For Open > Exploration to think about their NuPIC use-case of anomaly detection for > their aircraft and ship data. After viewing Chetan's video > <http://www.youtube.com/watch?v=KxxHo-FtKRo> on the geocoder and track > anomaly detection, I'd like to check my understanding. > > Take a situation in which you are encoding low speed object and a high > speed object, e.g. you driving on the freeway and me walking next to it. > When geocoder choses active squares in the box of the low speed object it > has relatively few squares to choose from. When the geocoder chooses the > same number of active squares for the high speed object, it has a much > larger number of squares to choose from. The highest ranking squares in the > larger box are likely to have higher rank than the squares in the smaller > box. I *think* what's going to happen is that there will be less overlap > between the active squares in nearby locations with different size boxes > than there is overlap in nearby locations with the same size boxes. This > means, that the sparse bit string representations of the fast object and > the slow object will have little overlap. In a sense this reflects one > kind of cognitive reality, when I'm walking along the sidewalk people > driving nearby might as well be in another Universe. On the other hand, if > I'm walking down the middle of the street you're going to be uncomfortably > close, but the geospatial encoder won't register this. > > Do I understand the situation? > > thanks, > Tom Taylor > Volatus Logic, LLC > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.numenta.org/pipermail/nupic-theory_lists.numenta.org/attachments/20150106/1f5f1130/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Tue, 6 Jan 2015 12:00:38 -0800 > From: Matthew Taylor <[email protected]> > To: NuPIC theory mailing list <[email protected]> > Subject: Re: a geocoder feature? > Message-ID: > < > cajv6ndm_jfnoqjtoxq4pve7h2aksv_p--hqes388ttavc5s...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Tom, thanks for sending. Yes, I think your question probably > belongs in the nupic-discuss list. > > See http://numenta.org/lists for descriptions of our mailing lists, > and please resend your question to [email protected] after > subscribing at > http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org. > > Thanks! > --------- > Matt Taylor > OS Community Flag-Bearer > Numenta > ------------------------------ > > Message: 3 > Date: Wed, 7 Jan 2015 08:43:32 +0000 > From: Fergal Byrne <[email protected]> > To: NuPIC theory mailing list <[email protected]> > Subject: Re: a geocoder feature? > Message-ID: > < > cad2q5yd6anjxgy5hw018pbaoj_bbbumoch27dovquddb9yw...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Thomas, > > That's a really good question. > > The overlap of the two representations is proportional (on average) to the > ratio of the shared area to the high-speed area, so the overlap will > gracefully go down from 100% (at matching speeds). Since there is always a > minimum area, even at zero speed, there will always be a significant > commonality between two representations at the same location, and always a > significant difference for different locations. The idea neatly encodes the > subjective experience of how our "sense of place" degrades when we're > travelling very fast. > > You're correct in surmising that this encoding is not suitable, per se, for > things like collision detection, but it might be adapted for things like > collision prediction, or at least for a useful "paranoid" safety system. > Because the encoding is very sparse, the overlap tells you how likely it is > that you (walking) are dangerously near me (driving). If there are any bits > in common between your SDR and my predicted next position, I should > probably use some other information to see if there's any danger. > > A real navigation system using this encoder would likely use both the > standard spatial reference frame (ie Lat-Long on the Earth's surface) and a > vehicle-centred reference frame to model other road users. In this > scenario, if your trajectory relative to me was predicted to enter a small > area around me, I would sound an alarm if I detected any bits in common > with position (0, 0, speed). > > Regards, > > Fergal Byrne > > -- > > Fergal Byrne, Brenter IT > > http://inbits.com - Better Living through Thoughtful Technology > http://ie.linkedin.com/in/fergbyrne/ - https://github.com/fergalbyrne > > Founder of Clortex: HTM in Clojure - > https://github.com/nupic-community/clortex > > Author, Real Machine Intelligence with Clortex and NuPIC > Read for free or buy the book at 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 > > 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 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.numenta.org/pipermail/nupic-theory_lists.numenta.org/attachments/20150107/d4f311d6/attachment-0001.html > > > >
