Roy Smith 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.
Sure it isn't. I think you stopped reading my post too early. None of your examples contradict what I am saying. They all involve exactly the same sort of compromise regarding "correctness" that I'm talking about, where you loosen what counts as "correct" for the purpose of getting extra speed. So, for example: > 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. What's your requirement, i.e. what counts as "correct" for the delivery algorithm being used? Is it that every parcel is delivered to the specified delivery address the first time? No it is not. What counts as "correct" for the delivery algorithm is something on the lines of "No less than 95% of parcels will be sorted correctly and delivered directly; no more than 5% may be mis-sorted at most three times" (or some similar requirement). It may even been that the requirements are even looser, e.g.: "No more than 1% of parcels will be lost/damaged/stolen/destroyed" in which case they don't care unless a particular driver loses or destroys more than 1% of his deliveries. But if it turns out that Fred is dumping every single one of his parcels straight into the river, the fact that he can make thirty deliveries in the time it takes other drivers to make one will not save his job. "But it's much faster to dump the parcels in the river" does not matter. What matters is that the deliveries are made within the bounds of allowable time and loss. Things get interesting when the people setting the requirements and the people responsible for meeting those requirements aren't able to agree. Then you have customers who complain that the software is buggy, and developers who complain that the customer requirements are impossible to provide. Sometimes they're both right. > 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. I've heard of Jeopardy, but never seen it. But I know about game shows, and in this case, what you care about is *winning the game*, not answering the questions correctly. Answering the questions correctly is only a means to the end, which is "Win". If the rules allow it, your best strategy might even be to give wrong answers, every time! (It's not quite a game show, but the British quiz show QI is almost like that. The rules, if there are any, encourage *interesting* answers over correct answers. Occasionally that leads to panelists telling what can best be described as utter porkies[1].) If Jeopardy does not penalise wrong answers, the "best" strategy might be to jump in with an answer as quickly as possible, without caring too much about whether it is the right answer. But if Jeopardy penalises mistakes, then the "best" strategy might be to take as much time as you can to answer the question, and hope for others to make mistakes. That's often the strategy in Test cricket: play defensively, and wait for the opposition to make a mistake. > 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. And if you catch the ball, stick it in your pocket and race through all the bases, what's that? It's almost certainly faster than trying to play by the rules. If speed is all that matters, that's what people would do. But it isn't -- the "correct" strategy depends on many different factors, one of which is that you have a de facto time limit on deciding whether to swing or let the ball through. Your baseball example is no different from the example I gave before. "Find the optimal path for the Travelling Salesman Problem in a week's time", versus "Find a close to optimal path in three minutes" is conceptually the same problem, with the same solution: an imperfect answer *now* can be better than a perfect answer *later*. [1] Porkies, or "pork pies", from Cockney rhyming slang. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
