Fergal, For the quadcopter hack, we just measured the world, updated the CLA, and generated a control signal as often as we could, many times a second. We didn't encode time explicitly, we just assumed that each tick would happen at more or less a regular interval, so it shouldn't affect the CLA's ability to model the world.
Now, if we weren't in control of how often we could do measurements, and they happened at irregular intervals, then it might be useful to encode the time since the last measurement. But in this case we didn't think that was necessary. - Chetan On Thu, Nov 14, 2013 at 4:17 PM, Fergal Byrne <[email protected]>wrote: > Hi Mark, > > There are indeed two types of time in NuPIC. One is explicit, which is > when you feed a real timestamp in along with your data. This is usually > (but again it's controlled by flags) turned into semantic fields for time > of day, day of week, etc. This time data is part of the input. In hotgym, > for example, the power consumption will depend on the number of fat people > in the gym, which is related to the time of day. The temperature will also > fluctuate with the time of day. In an office building, only the cleaners > and a few promotion-seekers will be in at the weekend. So time is a type of > real-world data here. > > The other type of time is the timestep counter. Just like for us, NuPIC > does not really know its own timescales. This timestep counter is > implicitly absorbed by NuPIC when it receives sequences of input rows. It's > crucial for learning patterns, but has no explicit value in terms of > seconds or milliseconds - it's just steps. > > The guys who did the music learning at the first hackathon used the second > type of time, and they hacked the output so it would play back at the > real-time rate of the song. But there was no true timing in either the > input or the output - it could have been played back at any speed. > > Ask Chetan and the lads how they handled time with the quadcopter hack - > I'd be interested to see whether time was involved explicitly or implicitly. > > Regards, > > Fergal Byrne > > > On Thu, Nov 14, 2013 at 11:53 PM, Marek Otahal <[email protected]>wrote: > >> A conversation in another thread lead me thinking about time... >> Please read below for context. >> >> I'll discuss how to improve date encoder. and other ways of representing >> time. >> >> DateEncoder: >> from what Chetan said, time is represented as output of date encoder >> (used by OPF) and appended to normal input. >> >> P1: Problem: this time seems to be oriented at macro level -years, >> months, weeks... I want to measure in minutes, seconds, (milis?) -> we >> should make it possible to se scale for the time encoding. >> >> How I understand it, correlation works because close times ~ similar >> numbers ~ similar scalar representations ~ similar patterns. >> >> I1: Improvement: To strenghten this similarity, and stability, we could >> assign bigger #bits to higher time units - hour=20bits, minute=10bits, >> second=5. Would this help? Should the size be proportional to the time? >> representation of 1hr 60x bigger that repre of 1minute? >> >> ---------------------------------- >> >> Other ways to represent time: >> >> Sequential time - mentioned below, time does not have to be a field, but >> is always present within the system. The sensors are always streaming data >> (like our eyes, 24 frames per sec), with each step, connections >> (permanences) degrade, so unless supported by repetitive patterns in data, >> connections fade away. This is called (global) decay in NN and is present >> in OPF I think (although I don;t know if it actually works). >> >> Q1: Question: Hve there been experiments with this omni present >> sequential time? Why is it not used? It seems more natural to me than a >> "field for time" which we don't have in brains. >> >> A disadvantage is you cant ask "What the input looked like at time T", >> but usually you're interested in predicting next states in a sequence, >> which you could do. >> >> I2 Improvement: A way to stick with this method but reduce high >> computational demands is, do not run by a constant clock, run only on >> demand when there's new data. But mimick time by "punishing" more if the >> delay is high, the permanence drop is high as well. >> >> >> Thanks for ideas! >> >> >> On Thu, Nov 14, 2013 at 11:09 PM, Chetan Surpur <[email protected]>wrote: >> >>> I believe that if you provide the time as a field, it will be split up >>> into components (day of week, is weekend, etc.) and encoded as any ordinary >>> integer. So NuPIC won't treat this any differently than any other integer >>> field. The learning occurs online with every record, whether 10 minutes >>> have passed in the time field, or whether 1 hour has passed. Hope that >>> makes sense. >>> >> >> Hmm, little bit, but not much. There seems to be space for improvements. >> I like that time is not treated any different from other imputs. The scale >> might be a problem (you mention days, weeks, I'd like to use seconds..but >> it's just implementation.) >> >> One the 10minutes and 1hour example, that is wrong... eg when I touch a >> hot plate, pain arrives (split second) afterwards, so it's associated >> together. While meeting a girlfriend 1 hr later does not relate to that. >> This is how it works for humans, that's why they say you shouldn't beat >> dogs and children :) a long time after they did something wrong...they >> won't link it. >> >> So there must be a minimal change to the pattern going into the SP for >> the "reconstruction" to kick in. >> >> For example: >> >> {object | time} = input >> >> {A____|***___} and {____A|_***__} "A flipped in one timestep" wouldn't >> learn well, because the change is too big. >> but moving slowly {A____|***___}, {_A___|_***__} and {__A__|__***_} would >> learn well. Eg a rotating object on camera streamed every frame to CLA. >> >> The changes to pattens are slow, so TP and SP can learn it. You can see >> time always move to the right. We can tell ***___ and _***__ are similar >> times, while ***___ and ___*** are far away, so should be the object's >> representations at the givent times. >> >> That got me little sidetracked, interesting note is, time encoding works, >> because similar times have similar numbers (hrs, minutes, vary in seconds, >> say), and similar numbers have similar representations in nupic, thus >> similar patterns. >> >> >> >> >> >> >> On Thu, Nov 14, 2013 at 2:06 PM, Marek Otahal <[email protected]>wrote: >> >> On Thu, Nov 14, 2013 at 10:57 PM, Chetan Surpur <[email protected]>wrote: >> >>> You would show many variants of the same object in a short period of >>> time to the HTM. It will associate them together using temporal pooling, >>> and that's what gives you an invariant representation. Basically, time acts >>> as a supervisor to correlate the variations. >>> >> +1 on the time being correlation supervisor, as that's how our minds >> perceive it. >> >> Btw, how do "timed streams" work in Nupic? >> >> Is it you provide a field {data | time} , and the OPF model takes care of >> "when difference T - (T-1) is too big, supress connections"? >> >> Or in a sequential manner, eg sending a sample every 1 sec, degrading >> connections a bit every step. So say in 10 steps a connection is unlinked >> unless boosted by a "correlating" example on input? >> >> >> >> -- >> Marek Otahal :o) >> >> _______________________________________________ >> nupic mailing list >> [email protected] >> http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org >> >> > > > -- > > Fergal Byrne, Brenter IT > > <http://www.examsupport.ie>http://inbits.com - Better Living through > Thoughtful Technology > > e:[email protected] t:+353 83 4214179 > 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
