Mark, As for your hot plate example, I don't think it's the fact that the pain comes 1 second or 1 hour later that makes the difference, it's that 1 second's worth of inputs to the brain vs 1 hour's worth of inputs to the brain has been processed before the pain is processed.
One hypothesis is that the brain doesn't need to keep track of time internally, it just has a feel for how much relative time has passed due to how much input it's had to process and learn from since a particular event. Now, I don't know if this is the case, but suffice to say that in NuPIC, we can use time input as just another datum if we need, but if we just want to measure the relative passing of time, we can just let the number of records processed take care of correlating inputs that are close together in "time". - Chetan On Thu, Nov 14, 2013 at 3: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 > >
_______________________________________________ nupic mailing list [email protected] http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
