[Feature] Show waiting times/traffic for each location #523

Open
opened 2024-09-29 00:17:05 +00:00 by cirex-web · 4 comments
cirex-web commented 2024-09-29 00:17:05 +00:00 (Migrated from github.com)

Description

can be implemented through (but not limited to)

  • card swipes
    image

  • Grubhub orders

  • crowdsourced data

Designs

No response

### Description can be implemented through (but not limited to) - card swipes ![image](https://github.com/user-attachments/assets/563b1ea7-61c2-43ae-bde4-e1388b96cc62) - Grubhub orders - crowdsourced data ### Designs _No response_
GhostOf0days commented 2024-09-29 01:19:42 +00:00 (Migrated from github.com)

For reference, I copied this from the Slack, but implementing this will require probability theory. For GrubHub orders, the following can be slightly modified to also incorporate them. The difference between the first and third is the first will give more data, so we converge to the true value using the law of large numbers faster. See below:

This goes into probability theory, but the expected number of people that are at a restaurant/location in a given time period given sufficient samples is the expected value of a Poisson distribution. The estimated wait time until arrival is found through exponential distribution. If we define an arrival as the time when we get our order filled, we can find our estimated wait time as E[X^2]/2E[X] (called a residual life). Essentially, E[X] would be 1 over the number of orders filled per minute (expected value for an exponential distribution). E[X^2] = 2/((the number of orders filled per minute)^2). This can be found experimentally through observation. If we sample E[X] at certain intervals (say 10 minutes), we can continuously update E[X] to be (sum of values of E[X])/number of time intervals sampled (similar method for E[X^2]), and update the equation for expected wait time (E[X^2]/2E[X]) continuously through crowdsourcing. As the number of samples increases, E[X] should also get closer to its true value. This gives the expected time for the next order to be filled. Then multiply this by the average number of people in the line across all samples taken (this part should work in theory because the exponential distribution is memoryless; waiting time at time A should be same as some time later until we update our samples, i.e., whenever new data comes in). When new data comes in, we can replace the old waiting time with the new waiting time.

This should give good estimates for when there’s no one providing data. We can modify as required for a M/M/1 or M/M/c queue.

Btw, if anyone’s wondering how to get the formulas for expected values E[X] and E[X^2] for exponential distribution, the probability density function (pdf) of the exponential distribution is lambda * e ^ ((-lambda)(x)). Take the integral from 0 to infinity w.r.t. x of x^n * the pdf I just defined, where n is found from E[X^n] (also called the nth moment). Lambda is the number of orders filled per minute.

If you are confused on this math, please lmk.

For reference, I copied this from the Slack, but implementing this will require probability theory. For GrubHub orders, the following can be slightly modified to also incorporate them. The difference between the first and third is the first will give more data, so we converge to the true value using the law of large numbers faster. See below: This goes into probability theory, but the expected number of people that are at a restaurant/location in a given time period given sufficient samples is the expected value of a Poisson distribution. The estimated wait time until arrival is found through exponential distribution. If we define an arrival as the time when we get our order filled, we can find our estimated wait time as E[X^2]/2E[X] (called a residual life). Essentially, E[X] would be 1 over the number of orders filled per minute (expected value for an exponential distribution). E[X^2] = 2/((the number of orders filled per minute)^2). This can be found experimentally through observation. If we sample E[X] at certain intervals (say 10 minutes), we can continuously update E[X] to be (sum of values of E[X])/number of time intervals sampled (similar method for E[X^2]), and update the equation for expected wait time (E[X^2]/2E[X]) continuously through crowdsourcing. As the number of samples increases, E[X] should also get closer to its true value. This gives the expected time for the next order to be filled. Then multiply this by the average number of people in the line across all samples taken (this part should work in theory because the exponential distribution is memoryless; waiting time at time A should be same as some time later until we update our samples, i.e., whenever new data comes in). When new data comes in, we can replace the old waiting time with the new waiting time. This should give good estimates for when there’s no one providing data. We can modify as required for a M/M/1 or M/M/c queue. Btw, if anyone’s wondering how to get the formulas for expected values E[X] and E[X^2] for exponential distribution, the probability density function (pdf) of the exponential distribution is lambda * e ^ ((-lambda)(x)). Take the integral from 0 to infinity w.r.t. x of x^n * the pdf I just defined, where n is found from E[X^n] (also called the nth moment). Lambda is the number of orders filled per minute. If you are confused on this math, please lmk.
GhostOf0days commented 2024-09-29 01:24:10 +00:00 (Migrated from github.com)

The 2nd (grubhub) would be in addition to 1 (card swipes) or 3 (experimental data collection). 1st (card swipes) would just mean much easier to gather samples.

The 2nd (grubhub) would be in addition to 1 (card swipes) or 3 (experimental data collection). 1st (card swipes) would just mean much easier to gather samples.
GhostOf0days commented 2025-06-06 03:51:46 +00:00 (Migrated from github.com)
Will need to update method when we do. See https://www.math.unl.edu/~gledder1/Notes/428/Queueing%20Theory%20Notes.pdf.
GhostOf0days commented 2025-06-10 19:49:24 +00:00 (Migrated from github.com)
Also read https://www.statology.org/erlang-distribution/.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
ScottyLabs/eats#523
No description provided.