NPM has many libraries 1 for AI.
Pls isolate this into a module etc so it has a clear interface; we will be rewriting/extending this quite a lot. Kind of obvious.
This feature doesn't need to be the fastest code; but can Node fork() (yes 2 ), to avoid blocking the 1 thread HTTP/S server?

Goal: SC requested step1 version

  • Static set of heuristics
  • Have the 'weights', to apply in each metric; adjustable ideally by the user (likely to be something like 1.1).
  • Take a base figure “basic cost of a table for a cover” from the venue as a starting number.
  • Not all metrics will apply to a given time/table; work out the active ones.
  • Combine all relevant weights (of these metrics) with a multiply.
  • Multiply onto the base figure.
  • Feed back figure to venue owner.

Goal: Step2, make the code workout new metrics

  • This is the valuable bit.
  • US people like to use the word “deep”. AFAIA this means pure/ abstract. The famous google 'deep learning' is a tweak on neural nets.
  • Unless we can get a large volume of reference data; we cannot use a neural net.
  • I have made several expert systems. These are sufficiently well-known that I can put cost estimates on.

References

Appendix A: Initial list of metrics (SC to extend)

  • current bookings for that day
  • day of week
  • time of day
  • time of year (peak in summer)
  • nearness to holidays/festivals (list in a DB table?)
  • Cultural match to the event (i.e. Chinese venue at Chinese new year is more expensive)
  • Nearness to “an event”, this will need to be scraped, sample data sources 3 4 5. Pretending we are rich, we can buy data from a company to do the aggregation for us (easier). Otherwise, the next years event calendar will need to be imported
  • weather estimate (maybe drop this one)
  • size of booking (compared to venue) maybe up/ maybe down, but affects price
  • previous bookings (not sure if up or down here either)
  • lead time to desired date (long lead time, small increment; short lead time, bigger)
  • Noticeable multiply factor depending expected alcohol consumption (an alcohol bill will literally double raw cost)...
  • User demographics: SC says male == expensive, 30-40 == expensive,
  • Response from SC: It's important that the algorithm feeds into the CMS that the restaurant is using and knows the restaurant location - i.e. london vs Melbourne and how the external market conditions affect pricing... this translates to a day by day visual - i.e. Yellow is not a strong day in the calendar for a price hike - dark red would show a customer tolerance to pay more... e.g. 14 February --- dark red.

Appendix B: reference impl notes

  • define a rule as an object holding a weight (a float), a name (a string) and a JS function, which takes a booking object & returns true or false
  • define a venue as a set of tables, (in addition to current attributes)
  • a table is a js object with name, a size, a description, and a base cost
  • revise a booking to mention the table
  • use an impl of Rete to apply each rule to the base price
  • The rules processor will need all the data we have about the consumer; and all the event data