Blog "about python 3"

[Rustom Mody]

On Sun, Jan 5, 2014 at 8:50 AM, Roy Smith <roy at 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$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.
>
> 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]