Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #62898 > unrolled thread

Blog "about python 3"

Back to article view | Back to comp.lang.python

Contents

  Blog "about python 3" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-30 19:41 +0000
    Re: Blog "about python 3" Steven D'Aprano <steve@pearwood.info> - 2013-12-30 20:49 +0000
      Re: Blog "about python 3" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-30 21:29 +0000
      Re: Blog "about python 3" Ethan Furman <ethan@stoneleaf.us> - 2013-12-30 14:38 -0800
      Re: Blog "about python 3" Chris Angelico <rosuav@gmail.com> - 2013-12-31 12:09 +1100
      Re: Blog "about python 3" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-31 04:38 +0000
      Re: Blog "about python 3" Chris Angelico <rosuav@gmail.com> - 2013-12-31 15:44 +1100
      Re: Blog "about python 3" Ethan Furman <ethan@stoneleaf.us> - 2013-12-30 20:33 -0800
      Re: Blog "about python 3" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-31 04:59 +0000
      Re: Blog "about python 3" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-31 08:22 +0000
        Re: Blog "about python 3" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-31 20:53 +1100
          Re: Blog "about python 3" Antoine Pitrou <solipsis@pitrou.net> - 2013-12-31 14:13 +0000
            Re: Blog "about python 3" Roy Smith <roy@panix.com> - 2013-12-31 10:41 -0500
              Re: Blog "about python 3" Chris Angelico <rosuav@gmail.com> - 2014-01-01 02:54 +1100
              Re: Blog "about python 3" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-31 15:55 +0000
              Re: Blog "about python 3" Robin Becker <robin@reportlab.com> - 2014-01-02 17:36 +0000
                Re: Blog "about python 3" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-03 15:49 +1100
                  Re: Blog "about python 3" Terry Reedy <tjreedy@udel.edu> - 2014-01-03 04:01 -0500
                    Re: Blog "about python 3" wxjmfauth@gmail.com - 2014-01-03 02:10 -0800
                      Re: Blog "about python 3" Chris Angelico <rosuav@gmail.com> - 2014-01-03 21:24 +1100
                      Re: Blog "about python 3" Ethan Furman <ethan@stoneleaf.us> - 2014-01-03 08:56 -0800
                  Re: Blog "about python 3" Robin Becker <robin@reportlab.com> - 2014-01-03 12:28 +0000
                    Re: Blog "about python 3" Roy Smith <roy@panix.com> - 2014-01-03 09:57 -0500
                      Re: Blog "about python 3" Chris Angelico <rosuav@gmail.com> - 2014-01-04 02:32 +1100
                  Re: Blog "about python 3" Terry Reedy <tjreedy@udel.edu> - 2014-01-03 17:00 -0500
                  Re: Blog "about python 3" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-04 04:04 +0000
                    Re: Blog "about python 3" Roy Smith <roy@panix.com> - 2014-01-04 08:55 -0500
                      Re: Blog "about python 3" Chris Angelico <rosuav@gmail.com> - 2014-01-05 01:17 +1100
                        Re: Blog "about python 3" wxjmfauth@gmail.com - 2014-01-04 11:10 -0800
                          Re: Blog "about python 3" Terry Reedy <tjreedy@udel.edu> - 2014-01-04 17:46 -0500
                            Re: Blog "about python 3" wxjmfauth@gmail.com - 2014-01-05 06:23 -0800
                              Re: Blog "about python 3" Ned Batchelder <ned@nedbatchelder.com> - 2014-01-05 10:20 -0500
                              Re: Blog "about python 3" Terry Reedy <tjreedy@udel.edu> - 2014-01-05 17:14 -0500
                                Re: Blog "about python 3" wxjmfauth@gmail.com - 2014-01-07 05:34 -0800
                                  Re: Blog "about python 3" Terry Reedy <tjreedy@udel.edu> - 2014-01-07 09:54 -0500
                                  Re: Blog "about python 3" Tim Delaney <timothy.c.delaney@gmail.com> - 2014-01-08 09:38 +1100
                                  Re: Blog "about python 3" Terry Reedy <tjreedy@udel.edu> - 2014-01-07 19:02 -0500
                                    Re: Blog "about python 3" wxjmfauth@gmail.com - 2014-01-08 01:59 -0800
                                      Re: Blog "about python 3" Terry Reedy <tjreedy@udel.edu> - 2014-01-08 14:26 -0500
                                  Re: Blog "about python 3" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-08 20:04 +0000
                              Re: Blog "about python 3" Terry Reedy <tjreedy@udel.edu> - 2014-01-05 17:48 -0500
                          Re: Blog "about python 3" Chris Angelico <rosuav@gmail.com> - 2014-01-05 10:28 +1100
                      Re: Blog "about python 3" Ned Batchelder <ned@nedbatchelder.com> - 2014-01-04 12:51 -0500
                      Re: Blog "about python 3" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-05 13:27 +1100
                        Re: Blog "about python 3" Chris Angelico <rosuav@gmail.com> - 2014-01-05 13:32 +1100
                        Re: Blog "about python 3" MRAB <python@mrabarnett.plus.com> - 2014-01-05 02:41 +0000
                        Re: Blog "about python 3" Roy Smith <roy@panix.com> - 2014-01-04 22:20 -0500
                          Re: Blog "about python 3" Rustom Mody <rustompmody@gmail.com> - 2014-01-05 10:12 +0530
                            Re: Blog "about python 3" Roy Smith <roy@panix.com> - 2014-01-05 00:11 -0500
                          Re: Blog "about python 3" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-05 17:28 +1100
                            Re: Blog "about python 3" Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-01-05 14:05 -0500
                          Re: Blog "about python 3" Chris Angelico <rosuav@gmail.com> - 2014-01-05 15:01 +1100
                            Re: Blog "about python 3" Roy Smith <roy@panix.com> - 2014-01-05 11:34 -0500
                              Re: Blog "about python 3" Chris Angelico <rosuav@gmail.com> - 2014-01-06 03:51 +1100
                                Re: Blog "about python 3" Roy Smith <roy@panix.com> - 2014-01-05 12:09 -0500
                                Re: Blog "about python 3" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-06 11:42 +1100
                              Re: Blog "about python 3" Terry Reedy <tjreedy@udel.edu> - 2014-01-05 17:56 -0500
                              Re: Blog "about python 3" Chris Angelico <rosuav@gmail.com> - 2014-01-06 10:59 +1100
                              Re: Blog "about python 3" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-06 12:23 +1100
                                Re: Blog "about python 3" Chris Angelico <rosuav@gmail.com> - 2014-01-06 12:54 +1100
                                Re: Blog "about python 3" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-06 05:53 +0000
                        Re: Blog "about python 3" Devin Jeanpierre <jeanpierreda@gmail.com> - 2014-01-05 00:00 -0800
                          Re: Blog "about python 3" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-05 23:28 +1100
                            Re: Blog "about python 3" Chris Angelico <rosuav@gmail.com> - 2014-01-05 23:48 +1100
                            Re: Blog "about python 3" Roy Smith <roy@panix.com> - 2014-01-05 11:10 -0500
                        Re: Blog "about python 3" Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-01-05 13:51 -0500
              Re: Blog "about python 3" David Hutto <dwightdhutto@gmail.com> - 2014-01-02 13:25 -0500
              Re: Blog "about python 3" Terry Reedy <tjreedy@udel.edu> - 2014-01-02 13:37 -0500
              Re: Blog "about python 3" Antoine Pitrou <solipsis@pitrou.net> - 2014-01-02 23:57 +0000
              Re: Blog "about python 3" Robin Becker <robin@reportlab.com> - 2014-01-03 10:32 +0000
              Re: Blog "about python 3" Robin Becker <robin@reportlab.com> - 2014-01-03 11:14 +0000
                Re: Blog "about python 3" wxjmfauth@gmail.com - 2014-01-04 05:52 -0800
                  Re: Blog "about python 3" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-05 13:41 +1100
                    Re: Blog "about python 3" Chris Angelico <rosuav@gmail.com> - 2014-01-05 13:54 +1100
                      Re: Blog "about python 3" wxjmfauth@gmail.com - 2014-01-05 02:39 -0800
              Re: Blog "about python 3" Robin Becker <robin@reportlab.com> - 2014-01-03 11:37 +0000
              Re: Blog "about python 3" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-04 07:30 +0000
          Re: Blog "about python 3" Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-01-05 13:14 +0100
            Re: Blog "about python 3" Stefan Behnel <stefan_ml@behnel.de> - 2014-01-05 14:55 +0100
          Re: Blog "about python 3" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-05 13:10 +0000
      Re: Blog "about python 3" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-31 20:04 +1100
      Re: Blog "about python 3" Devin Jeanpierre <jeanpierreda@gmail.com> - 2013-12-30 20:25 -0800

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#63236

On 1/5/2014 9:23 AM, wxjmfauth@gmail.com wrote:

> My examples are ONLY ILLUSTRATING, this FSR
> is wrong by design,

Let me answer you a different way. If FSR is 'wrong by design', so are 
the alternatives. Hence, the claim is, in itself, useless as a guide to 
choosing. The choices:

* Keep the previous complicated system of buggy narrow builds on some 
systems and space-wasting wide builds on other systems, with Python code 
potentially acting differently on the different builds. I am sure that 
you agree that this is a bad design.

* Improved the dual-build system by de-bugging narrow builds. I proposed 
to do this (and gave Python code proving the idea) by adding the 
complication of an auxiliary array of indexes of astral chars in a 
UTF-16 string. I suspect you would call this design 'wrong' also.

* Use the memory-wasting UTF-32 (wide) build on all systems. I know you 
do not consider this 'wrong', but come on. From an information theoretic 
and coding viewpoint, it clearly is. The top (4th) byte is *never* used. 
The 3rd byte is *almost never* used. The 2nd byte usage ranges from 
common to almost never for different users.

Memory waste is also time waste, as moving information-free 0 bytes 
takes the same time as moving informative bytes.

Here is the beginning of the rationale for the FSR (from 
http://www.python.org/dev/peps/pep-0393/ -- have you ever read it?).

"There are two classes of complaints about the current implementation of 
the unicode type: on systems only supporting UTF-16, users complain that 
non-BMP characters are not properly supported. On systems using UCS-4 
internally (and also sometimes on systems using UCS-2), there is a 
complaint that Unicode strings take up too much memory - especially 
compared to Python 2.x, where the same code would often use ASCII 
strings...".

The memory waste was a reason to stick with 2.7. It could break code 
that worked in 2.x. By removing the waste, the FSR makes switching to 
Python 3 more feasible for some people. It was a response to real 
problems encountered by real people using Python. It fixed both classes 
of complaint about the previous system.

* Switch to the time-wasting UTF-8 for text storage, as some have done. 
This is different from using UTF-8 for text transmission, which I hope 
becomes the norm soon.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#63155

On Sun, Jan 5, 2014 at 9:46 AM, Terry Reedy <tjreedy@udel.edu> wrote:
> On 1/4/2014 2:10 PM, wxjmfauth@gmail.com wrote:
>>
>> Le samedi 4 janvier 2014 15:17:40 UTC+1, Chris Angelico a écrit :
>
>
>>> any, and Python has only one, idiot like jmf who completely
>
>
> Chris, I appreciate the many contributions you make to this list, but that
> does not exempt you from out standard of conduct.
>
>
>>> misunderstands what's going on and uses microbenchmarks to prove
>>> obscure points... and then uses nonsense to try to prove... uhh...
>
>
> Troll baiting is a form of trolling. I think you are intelligent enough to
> know this.  Please stop.

My apologies. I withdraw the aforequoted post. You and Ned are
correct, those comments were inappropriate. Sorry.

ChrisA

[toc] | [prev] | [next] | [standalone]

#63138

On 1/4/14 9:17 AM, Chris Angelico wrote:
> On Sun, Jan 5, 2014 at 12:55 AM, Roy Smith <roy@panix.com> wrote:
>> In article <mailman.4882.1388808283.18130.python-list@python.org>,
>>   Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>>
>>> Surely everybody prefers fast but incorrect code in
>>> preference to something that is correct but slow?
>>
>> I realize I'm taking this statement out of context, but yes, sometimes
>> fast is more important than correct.  Sometimes the other way around.
>
> More usually, it's sometimes better to be really fast and mostly
> correct than really really slow and entirely correct. That's why we
> use IEEE floating point instead of Decimal most of the time. Though
> I'm glad that Python 3 now deems the default int type to be capable of
> representing arbitrary integers (instead of dropping out to a separate
> long type as Py2 did), I think it's possibly worth optimizing small
> integers to machine words - but mainly, the int type focuses on
> correctness above performance, because the cost is low compared to the
> benefit. With float, the cost of arbitrary precision is extremely
> high, and the benefit much lower.
>
> With Unicode, the cost of perfect support is normally seen to be a
> doubling of internal memory usage (UTF-16 vs UCS-4). Pike and Python
> decided that the cost could, instead, be a tiny measure of complexity
> and actually *less* memory usage (compared to UTF-16, when lots of
> identifiers are ASCII). It's a system that works only when strings are
> immutable, but works beautifully there. Fortunately Pike doesn't have
> any, and Python has only one, idiot like jmf who completely
> misunderstands what's going on and uses microbenchmarks to prove
> obscure points... and then uses nonsense to try to prove... uhh...
> actually I'm not even sure what, sometimes. I wouldn't dare try to
> read his posts except that my mind's already in a rather broken state,
> as a combination of programming and Alice in Wonderland.
>
> ChrisA
>

I really wish we could discuss these things without baiting trolls.

-- 
Ned Batchelder, http://nedbatchelder.com

[toc] | [prev] | [next] | [standalone]

#63160

Roy Smith wrote:

> In article <mailman.4882.1388808283.18130.python-list@python.org>,
>  Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> 
>> Surely everybody prefers fast but incorrect code in
>> preference to something that is correct but slow?
> 
> I realize I'm taking this statement out of context, but yes, sometimes
> fast is more important than correct.

I know somebody who was once touring in the States, and ended up travelling
cross-country by road with the roadies rather than flying. She tells me of
the time someone pointed out that they were travelling in the wrong
direction, away from their destination. The roadie driving replied "Who
cares? We're making fantastic time!"

(Ah, the seventies. So many drugs...)

Fast is never more important than correct. It's just that sometimes you
might compromise a little (or a lot) on what counts as correct in order for
some speed.

To give an example, say you want to solve the Travelling Salesman Problem,
and find the shortest path through a whole lot of cities A, B, C, ..., Z.
That's a Hard Problem, expensive to solve correctly.

But if you loosen the requirements so that a correct solution no longer has
to be the absolutely shortest path, and instead accept solutions which are
nearly always close to the shortest (but without any guarantee of how
close), then you can make the problem considerably easier to solve.

But regardless of how fast your path-finder algorithm might become, you're
unlikely to be satisfied with a solution that travels around in a circle
from A to B a million times then shoots off straight to Z without passing
through any of the other cities.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#63161

On Sun, Jan 5, 2014 at 1:27 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> But regardless of how fast your path-finder algorithm might become, you're
> unlikely to be satisfied with a solution that travels around in a circle
> from A to B a million times then shoots off straight to Z without passing
> through any of the other cities.

On the flip side, that might be the best salesman your company has
ever known, if those three cities have the most customers!

ChrisA
wondering why nobody cares about the customers in TSP discussions

[toc] | [prev] | [next] | [standalone]

#63163

On 2014-01-05 02:32, Chris Angelico wrote:
> On Sun, Jan 5, 2014 at 1:27 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> But regardless of how fast your path-finder algorithm might become, you're
>> unlikely to be satisfied with a solution that travels around in a circle
>> from A to B a million times then shoots off straight to Z without passing
>> through any of the other cities.
>
> On the flip side, that might be the best salesman your company has
> ever known, if those three cities have the most customers!
>
> ChrisA
> wondering why nobody cares about the customers in TSP discussions
>
Or, for that matter, ISP customers who don't live in an urban area. :-)

[toc] | [prev] | [next] | [standalone]

#63165

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.

[toc] | [prev] | [next] | [standalone]

#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]

[toc] | [prev] | [next] | [standalone]

#63169

In article <mailman.4929.1388896998.18130.python-list@python.org>,
 Rustom Mody <rustompmody@gmail.com> wrote:

> 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 have no idea.  Like I said, the numbers are all fabricated.

I do have a friend who used to work for UPS.  He told me lots of UPS 
efficiency stories.  One of them had to do with mis-routed packages.  
IIRC, the process for dealing with a mis-routed package was to NOT waste 
any time trying to figure out why it was mis-routed.  It was just thrown 
back into the input hopper to go through the whole system again.  The 
sorting software kept track of how many times it had sorted a particular 
package.  Only after N attempts (where N was something like 3), was it 
kicked out of the automated process for human intervention.

[toc] | [prev] | [next] | [standalone]

#63170

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

[toc] | [prev] | [next] | [standalone]

#63212

On Sun, 05 Jan 2014 17:28:14 +1100, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following:


>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!
>
	Jeopardy partly derived from the game show scandals of the 50s ($64000
question; where it came out that some contestants were coached on answers).
Jeopardy's clues ARE the answers, and the contestants have to provide a
question that could be answered by that clue. Granted, modern Jeopardy's
responses are all in the "who|what|when|where was ..." realm.

>(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].)
>
	Would not work for Jeopardy. Hogwash responses will result in penalty
(losing the question $$$) and permitting the other two contestants to ring
in with their response.

	In the early days, one could ring in even while the question was being
read. They now don't activate the button until the "answer" has been
completely read (meaning contestants need to be quick on the button WHEN
the reading is over). The old days meant one could click as the clue was
revealed and thereby lock-in while having the whole reading AND the
15-30second response window in which to make a reply. Now they have to
compete at the end of the reading and then take advantage of only the
15-30second window.

>If Jeopardy does not penalise wrong answers, the "best" strategy might be to

	It does, though. You lose the amount of the answer (the "jeopardy") for
wrong response questions.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#63171

On Sun, Jan 5, 2014 at 2:20 PM, Roy Smith <roy@panix.com> wrote:
> 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.

That's a valid line of argument in big business, these days, because
we've been conditioned to accept low quality. But there are places
where quality trumps all, and we're happy to pay for that. Allow me to
expound two examples.

1) Amazon

http://www.amazon.com/exec/obidos/ASIN/1782010165/evertype-20

I bought this book a while ago. It's about the size of a typical
paperback. It arrived in a box too large for it on every dimension,
with absolutely no packaging. I complained. Clearly their algorithm
was: "Most stuff will get there in good enough shape, so people can't
be bothered complaining. And when they do complain, it's cheaper to
ship them another for free than to debate with them on chat." Because
that's what they did. Fortunately I bought the book for myself, not
for a gift, because the *replacement* arrived in another box of the
same size, with ... one little sausage for protection. That saved it
in one dimension out of three, so it arrived only slightly
used-looking instead of very used-looking. And this a brand new book.
When I complained the second time, I was basically told "any
replacement we ship you will be exactly the same". Thanks.

2) Bad Monkey Productions

http://kck.st/1bgG8Pl

The cheapest the book itself will be is $60, and the limited edition
early ones are more (I'm getting the gold level book, $200 for one of
the first 25 books, with special sauce). The people producing this are
absolutely committed to quality, as are the nearly 800 backers. If
this project is delayed slightly in order to ensure that we get
something fully awesome, I don't think there will be complaints. This
promises to be a beautiful book that'll be treasured for generations,
so quality's far FAR more important than the exact delivery date.

I don't think we'll ever see type #2 become universal, for the same
reason that people buy cheap Chinese imports in the supermarket rather
than something that costs five times as much from a specialist. The
expensive one might be better, but why bother? When the cheap one
breaks, you just get another. The expensive one might fail too, so why
take that risk?

But it's always a tradeoff, and there'll always be a few companies
around who offer the more expensive product. (We have a really high
quality cheese slicer. It's still the best I've seen, after something
like 20 years of usage.) Fast or right? It'd have to be really
*really* fast to justify not being right, unless the lack of rightness
is less than measurable (like representing time in nanoseconds -
anything smaller than that is unlikely to be measurable on most
computers).

ChrisA

[toc] | [prev] | [next] | [standalone]

#63199

In article <mailman.4930.1388908293.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> On Sun, Jan 5, 2014 at 2:20 PM, Roy Smith <roy@panix.com> wrote:
> > 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.
> 
> That's a valid line of argument in big business, these days, because
> we've been conditioned to accept low quality. But there are places
> where quality trumps all, and we're happy to pay for that. Allow me to
> expound two examples.
> 
> 1) Amazon
> 
> http://www.amazon.com/exec/obidos/ASIN/1782010165/evertype-20
> 
> I bought this book a while ago. It's about the size of a typical
> paperback. It arrived in a box too large for it on every dimension,
> with absolutely no packaging. I complained. Clearly their algorithm
> was: "Most stuff will get there in good enough shape, so people can't
> be bothered complaining. And when they do complain, it's cheaper to
> ship them another for free than to debate with them on chat."

You're missing my point.

Amazon's (short-term) goal is to increase their market share by 
undercutting everybody on price.  They have implemented a box-packing 
algorithm which clearly has a bug in it.  You are complaining that they 
failed to deliver your purchase in good condition, and apparently don't 
care.  You're right, they don't.  The cost to them to manually correct 
this situation exceeds the value.  This is one shipment.  It doesn't 
matter.  You are one customer, you don't matter either.  Seriously.  
This may be annoying to you, but it's good business for Amazon.  For 
them, fast and cheap is absolutely better than correct.

I'm not saying this is always the case.  Clearly, there are companies 
which have been very successful at producing a premium product (Apple, 
for example).  I'm not saying that fast is always better than correct.  
I'm just saying that correct is not always better than fast.

[toc] | [prev] | [next] | [standalone]

#63201

On Mon, Jan 6, 2014 at 3:34 AM, Roy Smith <roy@panix.com> wrote:
> Amazon's (short-term) goal is to increase their market share by
> undercutting everybody on price.  They have implemented a box-packing
> algorithm which clearly has a bug in it.  You are complaining that they
> failed to deliver your purchase in good condition, and apparently don't
> care.  You're right, they don't.  The cost to them to manually correct
> this situation exceeds the value.  This is one shipment.  It doesn't
> matter.

If it stopped there, it would be mildly annoying ("1% of our shipments
will need to be replaced, that's a 1% cost for free replacements").
The trouble is that they don't care about the replacement either, so
it's really that 100% (or some fairly large proportion) of their
shipments will arrive with some measure of damage, and they're hoping
that their customers' threshold for complaining is often higher than
the damage sustained. Which it probably is, a lot of the time.

> You are one customer, you don't matter either.  Seriously.
> This may be annoying to you, but it's good business for Amazon.  For
> them, fast and cheap is absolutely better than correct.

But this is the real problem, business-wise. Can you really run a
business by not caring about your customers? (I also think it's pretty
disappointing that a business like Amazon can't just toss in some
bubbles, or packing peanuts (what we call "trucks" for hysterical
raisins), or something. It's not that hard to have a machine just blow
in some sealed air before the box gets closed... surely?) Do they have
that much of a monopoly, or that solid a customer base, that they're
happy to leave *everyone* dissatisfied? We're not talking about 1%
here. From the way the cust svc guy was talking, I get the impression
that they do this with all parcels.

And yet.... I can't disagree with your final conclusion. Empirical
evidence goes against my incredulous declaration that "surely this is
a bad idea" - according to XKCD 1165, they're kicking out nearly a
cubic meter a *SECOND* of packages. That's fairly good evidence that
they're doing something that, whether it be right or wrong, does fit
with the world's economy. Sigh.

ChrisA

[toc] | [prev] | [next] | [standalone]

#63203

Chris Angelico <rosuav@gmail.com> wrote:

> Can you really run a business by not caring about your customers?

http://snltranscripts.jt.org/76/76aphonecompany.phtml

[toc] | [prev] | [next] | [standalone]

#63250

Chris Angelico wrote about Amazon:

> And yet.... I can't disagree with your final conclusion. Empirical
> evidence goes against my incredulous declaration that "surely this is
> a bad idea" - according to XKCD 1165, they're kicking out nearly a
> cubic meter a SECOND of packages.

Yes, but judging by what you described as their packing algorithm that's
probably only a tenth of a cubic metre of *books*, the rest being empty box
for the book to rattle around in and get damaged.

-- 
Steven

[toc] | [prev] | [next] | [standalone]

#63238

On 1/5/2014 11:51 AM, Chris Angelico wrote:
> On Mon, Jan 6, 2014 at 3:34 AM, Roy Smith <roy@panix.com> wrote:
>> Amazon's (short-term) goal is to increase their market share by
>> undercutting everybody on price.  They have implemented a box-packing
>> algorithm which clearly has a bug in it.  You are complaining that they
>> failed to deliver your purchase in good condition, and apparently don't
>> care.  You're right, they don't.  The cost to them to manually correct
>> this situation exceeds the value.  This is one shipment.  It doesn't
>> matter.
>
> If it stopped there, it would be mildly annoying ("1% of our shipments
> will need to be replaced, that's a 1% cost for free replacements").
> The trouble is that they don't care about the replacement either, so
> it's really that 100% (or some fairly large proportion) of their
> shipments will arrive with some measure of damage, and they're hoping
> that their customers' threshold for complaining is often higher than
> the damage sustained. Which it probably is, a lot of the time.

My wife has gotten several books from Amazon and partners and we have 
never gotten one loose enough in a big enough box to be damaged. Either 
the box is tight or has bubble packing. Leaving aside partners, maybe 
distribution centers have different rules.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#63243

On Mon, Jan 6, 2014 at 9:56 AM, Terry Reedy <tjreedy@udel.edu> wrote:
> On 1/5/2014 11:51 AM, Chris Angelico wrote:
>>
>> On Mon, Jan 6, 2014 at 3:34 AM, Roy Smith <roy@panix.com> wrote:
>>>
>>> Amazon's (short-term) goal is to increase their market share by
>>> undercutting everybody on price.  They have implemented a box-packing
>>> algorithm which clearly has a bug in it.  You are complaining that they
>>> failed to deliver your purchase in good condition, and apparently don't
>>> care.  You're right, they don't.  The cost to them to manually correct
>>> this situation exceeds the value.  This is one shipment.  It doesn't
>>> matter.
>>
>>
>> If it stopped there, it would be mildly annoying ("1% of our shipments
>> will need to be replaced, that's a 1% cost for free replacements").
>> The trouble is that they don't care about the replacement either, so
>> it's really that 100% (or some fairly large proportion) of their
>> shipments will arrive with some measure of damage, and they're hoping
>> that their customers' threshold for complaining is often higher than
>> the damage sustained. Which it probably is, a lot of the time.
>
>
> My wife has gotten several books from Amazon and partners and we have never
> gotten one loose enough in a big enough box to be damaged. Either the box is
> tight or has bubble packing. Leaving aside partners, maybe distribution
> centers have different rules.

Or possibly (my personal theory) the CS rep I was talking to just
couldn't be bothered solving the problem. Way way too much work to
make the customer happy, much easier and cheaper to give a 30% refund
and hope that shuts him up.

But they managed to ship two books (the original and the replacement)
with insufficient packaging. Firstly, that requires the square of the
probability of failure; and secondly, if you care even a little bit
about making your customers happy, put a little note on the second
order instructing people to be particularly careful of this one! Get
someone to check it before it's sent out. Make sure it's right this
time. I know that's what we used to do in the family business whenever
anything got mucked up.

(BTW, I had separately confirmed that the problem was with Amazon, and
not - as has happened to me with other shipments - caused by
Australian customs officials opening the box, looking through it, and
then packing it back in without its protection. No, it was shipped
that way.)

Anyway, this is veering so far off topic that we're at no risk of
meeting any Python Alliance ships - as Mal said, we're at the corner
of No and Where. But maybe someone can find an on-topic analogy to put
some tentative link back into this thread...

ChrisA

[toc] | [prev] | [next] | [standalone]

#63252

Roy Smith wrote:

> In article <mailman.4930.1388908293.18130.python-list@python.org>,
>  Chris Angelico <rosuav@gmail.com> wrote:
> 
>> On Sun, Jan 5, 2014 at 2:20 PM, Roy Smith <roy@panix.com> wrote:
>> > 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.
>> 
>> That's a valid line of argument in big business, these days, because
>> we've been conditioned to accept low quality. But there are places
>> where quality trumps all, and we're happy to pay for that. Allow me to
>> expound two examples.
>> 
>> 1) Amazon
>> 
>> http://www.amazon.com/exec/obidos/ASIN/1782010165/evertype-20
>> 
>> I bought this book a while ago. It's about the size of a typical
>> paperback. It arrived in a box too large for it on every dimension,
>> with absolutely no packaging. I complained. Clearly their algorithm
>> was: "Most stuff will get there in good enough shape, so people can't
>> be bothered complaining. And when they do complain, it's cheaper to
>> ship them another for free than to debate with them on chat."
> 
> You're missing my point.
> 
> Amazon's (short-term) goal is to increase their market share by
> undercutting everybody on price.  They have implemented a box-packing
> algorithm which clearly has a bug in it.  You are complaining that they
> failed to deliver your purchase in good condition, and apparently don't
> care.  You're right, they don't.  The cost to them to manually correct
> this situation exceeds the value.  This is one shipment.  It doesn't
> matter.  You are one customer, you don't matter either.  Seriously.
> This may be annoying to you, but it's good business for Amazon.  For
> them, fast and cheap is absolutely better than correct.

One, you're missing my point that to Amazon, "fast and cheap" *is* correct.
They would not agree with you that their box-packing algorithm is buggy, so
long as their customers don't punish them for it. It meets their
requirements: ship parcels as quickly as possible, and push as many of the
costs (damaged books) onto the customer as they can get away with. If they
thought it was buggy, they would be trying to fix it.

Two, nobody is arguing against the concept that different parties have
different concepts of what's correct. To JMF, the flexible string
representation is buggy, because he's detected a trivially small slowdown
in some artificial benchmarks. To everyone else, it is not buggy, because
it does what it sets out to do: save memory while still complying with the
Unicode standard. A small slowdown on certain operations is a cost worth
paying.

Normally, the definition of "correct" that matters is that belonging to the
paying customer, or failing that, the programmer who is giving his labour
away for free. (Extend this out to more stakeholders if you wish, but the
more stakeholders you include, the harder it is to get consensus on what's
correct and what isn't.) From the perspective of Amazon's customers,
presumably so long as the cost of damaged and lost books isn't too high,
they too are willing to accept Amazon's definition of "correct" in order to
get cheap books, or else they would buy from someone else.

(However, to the extent that Amazon has gained monopoly power over the book
market, that reasoning may not apply. Amazon is not *technically* a
monopoly, but they are clearly well on the way to becoming one, at which
point the customer has no effective choice and the market is no longer
free.)

The Amazon example is an interesting example of market failure, in the sense
that the free market provides a *suboptimal solution* to a problem. We'd
all like reasonably-priced books AND reliable delivery, but maybe we can't
have both. Personally, I'm not so sure about that. Maybe Jeff Bezos could
make do with only five solid gold Mercedes instead of ten[1], for the sake
of improved delivery? But apparently not.

But I digress... ultimately, you are trying to argue that there is a single
absolute source of truth for what counts as "correct". I don't believe
there is. We can agree that some things are clearly not correct -- Amazon
takes your money and sets the book on fire, or hires an armed military
escort costing $20 million a day to deliver your book of funny cat
pictures. We might even agree on what we'd all like in a perfect world:
cheap books, reliable delivery, and a pony. But in practice we have to
choose some features over others, and compromise on requirements, and
ultimately we have to make a *pragmatic* choice on what counts as correct
based on the functional requirements, not on a wishlist of things we'd like
with infinite time and money.

Sticking to the Amazon example, what percentage of books damaged in delivery
ceases to be a bug in the packing algorithm and becomes "just one of those
things"? One in ten? One in ten thousand? One in a hundred billion billion?
I do not accept that "book gets damaged in transit" counts as a bug. "More
than x% of books get damaged", that's a bug. "Average cost to ship a book
is more than $y" is a bug. And Amazon gets to decide what the values of x%
and $y are.


> I'm not saying this is always the case.  Clearly, there are companies
> which have been very successful at producing a premium product (Apple,
> for example).  I'm not saying that fast is always better than correct.
> I'm just saying that correct is not always better than fast.

In the case of Amazon, "correct" in the sense of "books are packed better"
is not better than fast. It's better for the customer, and better for
society as a whole (less redundant shipping and less ecological harm), but
not better for Amazon. Since Amazon gets to decide what's better, their
greedy, short-term outlook wins, at least until such time as customers find
an alternative. Amazon would absolutely not agree with you that packing the
books more securely is "better", if they did, they would do it. They're not
stupid, just focused on short-term gain for themselves at the expense of
everyone else. (Perhaps a specialised, and common, form of stupidity.)

By the way, this whole debate is known as "Worse is better", and bringing it
back to programming languages and operating systems, you can read more
about it here:

http://www.jwz.org/doc/worse-is-better.html



[1] Figuratively speaking.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#63256

On Mon, Jan 6, 2014 at 12:23 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> (However, to the extent that Amazon has gained monopoly power over the book
> market, that reasoning may not apply. Amazon is not *technically* a
> monopoly, but they are clearly well on the way to becoming one, at which
> point the customer has no effective choice and the market is no longer
> free.)

They don't need a monopoly on the whole book market, just on specific
books - which they did have, in the cited case. I actually asked the
author (translator, really - it's a translation of "Alice in
Wonderland") how he would prefer me to buy, as there are some who sell
on Amazon and somewhere else. There was no alternative to Amazon, ergo
no choice and the market was not free. Like so many things, one choice
("I want to buy Ailice's Anters in Ferlielann") mandates another
("Must buy through Amazon").

I don't know what it cost Amazon to ship me two copies of a book, but
still probably less than they got out of me, so they're still ahead.
Even if they lost money on this particular deal, they're still way
ahead because of all the people who decide it's not worth their time
to spend an hour or so trying to get a replacement. So yep, this
policy is serving Amazon fairly well.

ChrisA

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.python

csiph-web