Hi Alan, Here are my comments about your questions.
1.a. This was an ad-hoc idea, but I haven't tried it. 1.a.i.-ii. Ideally, you would not want to include this field at all, you would just have years worth of data an a learned model that has seen the patterns each holiday produced in the past. But since you don't have that kind of history, you'll need to experiment a little. Perhaps a simple countup isn't going to give you what you want... if a holiday like XMas is a big deal, maybe its value is higher and there is a longer countup to that date, rather than say St. Patrick's Day. Like I said, this was just an ad-hoc idea and I can't say for certain how it will work. You'll want to experiment with it. 2. If you have data for 15 locations, I would say that each location should have its own model. One model only make predictions for one field, anyway. 2.a. You would only lose value if there are correlations between the locations, but I imagine this is not the case. The frequency of deliveries at one restaurant are probably not directly affected by the frequency of deliveries at another. 2.b. No. By the way, is this an HTM Challenge project? Regards, --------- Matt Taylor OS Community Flag-Bearer Numenta On Mon, Oct 26, 2015 at 1:27 PM, Alan Haverty <[email protected]> wrote: > Hello Nupic, > > > I have some questions about feeding in known events and also, how I should > handle multiple 'locations' that have similar properties but that may not > be directly related in reality. > > > Please let me know if I'm asking in the wrong mail list. > > I'm also providing a brief description and example of the project. > Outline of Problem > > Restaurants that offer food delivery are forced to hire drivers, pay for > insurance, pay for wages + predict how many drivers are needed in advance > and schedule their hours. > > > I propose to abstract this as a service where restaurants can simply use > an app to request a driver and let this service-business worry about > drivers, insurance, wages, roster scheduling etc. > > > To achieve this, the central ‘delivery system’ needs to predict how many > jobs are going to come from each area within a city to allow scheduling of > drivers days/weeks in advance. > > > I believe NuPIC is ideal to solve this problem, but I have a few questions > that I hope the mailing list can help with. > > > *Assuming for this example:* > > - That a city is divided into 15 geographical areas. > - That I have 3 months of known data with the amount of total > deliveries that came from each area per hour. > - That I need to predict the number_of_deliveries per hour (days/week > in advance, not too concerned with how far in advance yet.) > > Example Data > > *Example of 3hrs of data for one of those 15 areas:* > > *dttm* > > *number_of_deliveries* > > *datetime* > > *int* > > *T* > > 2015/08/01 00:00:00.0 > > 178 > > 2015/08/01 01:00:00.0 > > 96 > > 2015/08/01 02:00:00.0 > > 52 > > > Questions > > 1. 1. If I want to incorporate event data for known upcoming events > such as a national holiday/football game/TV series finale airing; how > should this hourly event data be arranged? > > a. Matthew Taylor suggested > <https://www.youtube.com/watch?v=gYOwBlVuJDw> to use a count down until > the hours of the event > > i. How > would this work if I wanted to weight certain events differently? (e.g. A > national bank holiday would be weighted higher than a television series > episode airing) > > ii. While > the event is occurring, how should the countdown be represented? Should it > be ..,5,4,3,2,1,1,1,1,1,…,1,20,19,.. *(Red being the event currently on > for that hour(s) or some cases the whole day(s))* > > 2. 2. I need to do this for multiple locations, would a field to > specify each location be correct (Meaning there would be x15 {Saturday @ > 12:00}, *one for each of the 15 locations*) or should they be totally > separated? > > a. If I separate locations completely, would you expect I lose > value in anyway? > > b. If I keep them together, could locations contaminate/effect each > other that may not happen in reality? > > *c. **Apologies for this broad question, if anyone could even point > me to suggested reading, I would appreciate it.* > Thank you for reading! > > > > *Best regards, Alan Haverty**[email protected] <[email protected]>* > >
