Blog "about python 3"

[Steven D'Aprano]

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$5496439d at news.astraweb.com>,
>  Steven D'Aprano <steve+comp.lang.python at 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