Hi Mark, As I explained, time is often a datum in its own right. When learning the cycles of power consumption in hotgym, the time of day and day of the week are the most important determiners of power usage - the gym is closed at night and there are peaks before and after the business day as people go to the gym before and after work. Time in this sense is data just like any other kind.
In NuPIC, you don't do anything between inputs. The inputs decide the timesteps - one per record, and NuPIC runs only when you call it with a new record. NuPIC learns sequences, but there's no "between" between any two timesteps. Regards, Fergal Byrne On Fri, Nov 15, 2013 at 12:54 AM, Marek Otahal <[email protected]> wrote: > 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 > > -- 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
