Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!eweka.nl!lightspeed.eweka.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!news.tele.dk!news.tele.dk!small.news.tele.dk!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <roy-BB1659.22204004012014@news.panix.com>
References: <mailman.4724.1388432539.18130.python-list@python.org> <52c1dc4c$0$2877$c3e8da3$76491128@news.astraweb.com> <l9soij$ck6$1@ger.gmane.org> <52C1F5EC.3020808@stoneleaf.us> <mailman.4748.1388478161.18130.python-list@python.org> <52c29416$0$29987$c3e8da3$5496439d@news.astraweb.com> <mailman.4753.1388499265.18130.python-list@python.org> <roy-4C0A2F.10412731122013@news.panix.com> <mailman.4797.1388684229.18130.python-list@python.org> <52c6415c$0$29972$c3e8da3$5496439d@news.astraweb.com> <la5u8j$hqr$1@ger.gmane.org> <52C6AD00.5050000@chamonix.reportlab.co.uk> <la7btn$u5$1@ger.gmane.org> <mailman.4882.1388808283.18130.python-list@python.org> <roy-1820F1.08551004012014@news.panix.com> <52c8c301$0$29998$c3e8da3$5496439d@news.astraweb.com> <roy-BB1659.22204004012014@news.panix.com>
From: Rustom Mody <rustompmody@gmail.com>
Date: Sun, 5 Jan 2014 10:12:47 +0530
Subject: Re: Blog "about python 3"
To: Roy Smith <roy@panix.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "python-list@python.org" <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.4929.1388896998.18130.python-list@python.org>
Lines: 85
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:63168

On Sun, Jan 5, 2014 at 8:50 AM, Roy Smith <roy@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@news.astraweb.com>,
>  Steven D'Aprano <steve+comp.lang.python@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]