On Sun, Jan 5, 2014 at 8:50 AM, Roy Smith <r...@panix.com> wrote: > I wrote: >> > I realize I'm taking this statement out of context, but yes, sometimes >> > fast is more important than correct. > > In article <52c8c301$0$29998$c3e8da3$54964...@news.astraweb.com>, > Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: >> Fast is never more important than correct. > > Sure it is. > > Let's imagine you're building a system which sorts packages for > delivery. You sort 1 million packages every night and put them on > trucks going out for final delivery. > > Some assumptions: > > Every second I can cut from the sort time saves me $0.01. > > If I mis-sort a package, it goes out on the wrong truck, doesn't get > discovered until the end of the day, and ends up costing me $5 > (including not just the direct cost of redelivering it, but also > factoring in ill will and having to make the occasional refund for not > meeting the promised delivery time). > > I've got a new sorting algorithm which is guaranteed to cut 10 seconds > off the sorting time (i.e. $0.10 per package). The problem is, it makes > a mistake 1% of the time. > > Let's see: > > 1 million packages x $0.10 = $100,000 saved per day because I sort them > faster. 10,000 of them will go to the wrong place, and that will cost > me $50,000 per day. By going fast and making mistakes once in a while, > I increase my profit by $50,000 per day. > > The numbers above are fabricated, but I'm sure UPS, FexEx, and all the > other package delivery companies are doing these sorts of analyses every > day. I watch the UPS guy come to my house. He gets out of his truck, > walks to my front door, rings the bell, waits approximately 5 > microseconds, leaves the package on the porch, and goes back to his > truck. I'm sure UPS has figured out that the amortized cost of the > occasional stolen or lost package is less than the cost for the delivery > guy to wait for me to come to the front door and sign for the delivery. > > Looking at another problem domain, let's say you're a contestant on > Jeopardy. If you listen to the entire clue and spend 3 seconds making > sure you know the correct answer before hitting the buzzer, it doesn't > matter if you're right or wrong. Somebody else beat you to the buzzer, > 2.5 seconds ago. > > Or, let's take an example from sports. I'm standing at home plate > holding a bat. 60 feet away from me, the pitcher is about to throw a > baseball towards me at darn close to 100 MPH (insert words like "bowl" > and "wicket" as geographically appropriate). 400 ms later, the ball is > going to be in the catcher's glove if you don't hit it. If you have an > absolutely perfect algorithm to determining if it's a ball or a strike, > which takes 500 ms to run, you're going back to the minor leagues. If > you have a 300 ms algorithm which is right 75% of the time, you're > heading to the hall of fame.
Neat examples -- thanks Only minor quibble isnt $5 cost of mis-sorting a gross underestimate? I am reminded of a passage of Dijkstra in Discipline of Programming -- something to this effect He laments the fact that hardware engineers were not including overflow checks in machine ALUs. He explained as follows: If a test is moderately balanced (statistically speaking) a programmer will not mind writing an if statement If however the test is very skew -- say if 99% times, else 1% -- he will tend to skimp on the test, producing 'buggy' code [EWD would never use the bad b word or course] The cost equation for hardware is very different -- once the investment in the silicon is done with -- fixed cost albeit high -- there is no variable cost to executing that circuitry once or a zillion times Moral of Story: Intel should take up FSR [Ducks and runs for cover] -- https://mail.python.org/mailman/listinfo/python-list