Hi Fergal, thank you for your replies!
On Fri, Nov 15, 2013 at 1:17 AM, 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. > Yes, and what I'm saying is that everything can be represented as sequences. No need for explicit time, after all, we don't have a sensor for that (appart from wrist watch :) ) We do have a notion of time, but that's imho a higher level feature, so shouldn't need to be present at a CLA level. (If closed in an isolated dark room, soon you'd have trouble keeping track of the time. You could eg count, but that's because already as small babies in the belly, we listen to the mother's heartbeat.) > > 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. > This is what I call sequential time. It's just steps, what I proposed was a "hack" to save cycles when there's no input. If there's silence 10 steps between two inputs, instead of doing 10 blank runs, you just sit and when finally input arrives, you first reduce the connections by 10*_reductionPerStep. And then feed input. > > 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. > The implicit/sequence timing can be used imho for majority problems. To all periodic ones, just forget the time and treat it as a sequence. For streams with variable delays, you'd have to use greatest common divisor, so not suitable for data with intervals: minute, minute: hour: day: minute. But then, it's questionable the "daily" data has a correlation to the minute scale data at all? Eg this discussion does not really relate to me hitting the keys few times a second, but rather reading the email and composing the answer in the order of minutes. 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 For summary, I;d like to hear arguments why/where sequential time (at the level of CLA) shouldn't be enough and we need to use explicit time field. That reminds me how we remind things, unlike computer, we don't ask Where have I left my keys at 17 45? But rather, I got out of the car, put my coat on the hanger and sit for the coffee ....so the key is.. :) Thank you very much, Mark -- Marek Otahal :o)
_______________________________________________ nupic mailing list [email protected] http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
