161–170 of 172 posts
Earlier quoted context omitted.
Yes, and it is how real stores work, which is the point.
Right. I wonder what would happen if we try to include a measure of perceived fairness from the customer's point of view into this type of analysis. I always feel I'm picking the wrong queue at stores... single queues going to whatever cash is open seem fairer, if that makes sense.
Most of the grocery stores in my area have installed self-checkout systems that are especially great if you just have a handful of items that all have UPCs (no produce or bagged bulk), don't have any items requiring an age check and possess at least the intelligence of a fifth grader. I mention this not just because it's relevant to the idea of waiting in line at a store, but because in every store where I've seen th…
Here in San Diego we've had self-checkout systems in most major stores for a few years now. At first they were awesome because nobody used them, so you could zip right through and avoid the lines. But now, after they've been here for a few years, a lot more people feel comfortable using them but many of those people use them poorly and far too many people will use them even when they have an entire cart full of groce…
The one problem with the theory described above is that most walmarts have a 6 cashier express with a single line, and besides 'rush hour' when the store is packed it's often faster to go to a till to get Theory is great, but it's useless when you're stuck behind a bunch of old women who can't hear them being called and spend 20 minutes chatting with the cashier.
scala> import org.apache.commons.math.distribution.{ExponentialDistributionImpl=>expo} //pc = process customer, with a mean time mu per customer scala> def pc(mu:Int):Double= new expo(mu).sample // q = queue of n customers with mean process time mu scala> def q(n:Int,mu:Int):Double=(1 to n).map(_=>pc(mu)).sum scala> // put 3000 people in 1 queue with mean process time 50 scala> (1 to 1000).map(_=>q(3000,50)).sum/1000…
I am also very curious why the total time to process 3000 customers with mean time 50 is not closer to 3000*50. Perhaps I have missed something on the technical side.
scala> import org.apache.commons.math.distribution.{ExponentialDistributionImpl=>expo} //pc = process customer, with a mean time mu per customer scala> def pc(mu:Int):Double= new expo(mu).sample // q = queue of n customers with mean process time mu scala> def q(n:Int,mu:Int):Double=(1 to n).map(_=>pc(mu)).sum scala> // put 3000 people in 1 queue with mean process time 50 scala> (1 to 1000).map(_=>q(3000,50)).sum/1000…
Okay, someone with some Scala expertise needs to jump in here. The code as written is _clearly_ incorrect. q(n,mu) sums a distribution with mean mu n times. The expected value of this is mu * n. Then we run this 1000 times and average the results. If this is not extremely close to mu*n then I will eat my hat. In R, sum(replicate(1000,sum(rexp(3000,1/50)))) / 1000 returns ~150000 (using sum for clarity instead of mean…
The poster is a quant working with Scala so I am certain I have just misunderstood something. Nevertheless, my humble bachelor's degree has led me to the same conclusion as you.
Earlier quoted context omitted.
It's being rolled out slowly. Target in Emeryville has a rather advanced queuing system like this, but customers definitely don't like it and don't necessarily realize it's faster, perhaps because Target has less cashiers as a result of the decreased wait. Edit: Yelp says this line system has been eliminated. http://www.yelp.com/biz/target-emeryville-2
I went through that system a few times. They had a set of three lines (A,B,C) that fed a bank of cashiers; a screen overhead flashed instructions like "A => cashier 7", then "B => cashier 5" and then "C => cashier 1". It felt more stressful, efficiency be damned. You spend more time at the "front" of your line (A,B,C) , waiting for the board to change. In a traditional system you can hook in behind someone and "zone…
scala> import org.apache.commons.math.distribution.{ExponentialDistributionImpl=>expo} //pc = process customer, with a mean time mu per customer scala> def pc(mu:Int):Double= new expo(mu).sample // q = queue of n customers with mean process time mu scala> def q(n:Int,mu:Int):Double=(1 to n).map(_=>pc(mu)).sum scala> // put 3000 people in 1 queue with mean process time 50 scala> (1 to 1000).map(_=>q(3000,50)).sum/1000…
FYI: This is an example of the branch of mathematics called queueing theory. http://en.wikipedia.org/wiki/Queueing_theory It's a fascinating study requiring a good knowledge of probability to use beyond the simplified models. It turns out from the math that throughput using a single queue is better than using multiple queues.
Not trying to be condescending but doesn't it surprise anyone here that this is _not_ obvious? At least on this site, there are still people doubting or debating this. So I am wondering why don't stores do this already. And I believe it is because of perceptions. They understand that time will be saved, however, they realize that most people will be scared by a long line. One long line that moves fast will still appe…
Unfortunately that is the ONLY thing I got from that subject: "single line with lots of servers better than lots of lines with one server each". I can't really remember anything else, like WHY this is the case or how queues work. :/
Earlier quoted context omitted.
In my experience, the slow down is the cost of the extra features of the self-checkout system running on (I'm guessing) weak hardware. There is a rather large delay when choosing payment sources or in between bagging items.
Between bagging items, it has to wait for the scales underneath the bagging area to register a consistent weight. When choosing a payment source, it probably has to do a network call to the PIN-pad system. It's not like it's running on a slow CPU.
Earlier quoted context omitted.
Between bagging items, it has to wait for the scales underneath the bagging area to register a consistent weight. When choosing a payment source, it probably has to do a network call to the PIN-pad system. It's not like it's running on a slow CPU.
Good point. At any rate, there is room for improvement, especially considering the normal checkout systems appear to perform more quickly.
Earlier quoted context omitted.
>everyone uses different variables and judgment to make that prediction. Those variables and those predictions don't show up when your model is based on distributions. Sorry but that's simply not true. everyone uses different variables and judgment to make a phone call, yet phone calls follow an exponential distribution! everyone uses different variables and judgment to hit the internet, yet network traffic follows a…
"Phone calls follow an exponential distribution" I'm confused as to the meaning there. What is it about phone calls that follow an exponential distribution? Their duration? Their quantity per capita per time of day?
Sorry for the confusion. Lemme clarify a bit. Say you work at an office. 9am to 5pm. 8 hours a day.
scala> 60x60x8
res45: Int = 28800
So a phone call can arrive in any one of those 28,800 seconds. Putting it another way, the probability p of getting a phone call at any particular second is very remote, but the number of seconds aka trials is n=28800 ie. very large. Anytime you have very small p and very large n, that's a nice candidate for a particular member of the exponential family of distributions. In this case, the arrival times of phone calls to your office will be Poisson.
Say you hire an office assistant to count the number of phone calls every day, and she tells you after a month that your office averages say 24 calls a day. That 24 is your mu, the mean of the Poison distribution.At that point you know everything you need to know about the distribution, because Poisson is a discrete distribution whose probability p is specified entirely by the mean mu!
So you can go off and compute the probability p like so:
scala> import scala.math.{exp,pow}
scala> def fact(n:Int):Int = { if( n>1) nfact(n-1) else 1}
scala> def p(mu:Int,n:Int) = {pow(mu,n)exp(-mu)/fact(n)}
The chances of your office getting 4 or fewer phone calls by noon is then easy to figure out. Since you average 24 calls in 8 hours, you should average 9 calls by noon. So the probability of getting 4 or fewer calls would be
scala> (0 to 4).map(p(9,_)).sum
res46: Double = 0.05496364149510491
So you have a 5% chance of getting 4 or fewer calls by noon. If someone offers to bet a million dollars that your office will get 4 or fewer calls by noon, the odds of winning that bet are 1 in 19.
edit:formatted for better readability.