pairs from a list

[George Sakkis]

Re: pairs from a list

On Jan 23, 1:30 pm, Paddy <paddy3...@goog lemail.comwrote :

I've heard quality expressed as "meeting requirements", which I think
is apt. Falling short of requirements everyone knows doesn't give a
quality result, but equally 'exceeding' requirements also detracts
from quality (as does not knowing your requirements).
It is good to learn optimization techniques, which may be part of what
you are saying, but part of that is learning when it pays to apply
them and/or search for them; and when it does not.

The OP wanted an answer to a simple question, not a lecture on good
software engineering principles. This whole subthread reminds of a
movie (can't remember which) where someone asks his buddy in the
stadium "what do you want?". His buddy gets it wrong and embarks in a
long diatribe of what he wants in life now, what he wanted as a child,
what's the meaning of one's life and so on. After a couple of minutes
the guy cuts him and asks again:
- "Man, what do you want, burger or hot dog?"
- "Oh, a hot dog".

Sometimes you want to see the tree right in front of you, not the
whole damn forest.

George

[Arnaud Delobelle]

Re: pairs from a list

On Jan 23, 7:06 pm, George Sakkis <george.sak...@ gmail.comwrote:

The OP wanted an answer to a simple question, not a lecture on good
software engineering principles.

I wholeheartedly agree.

--
Arnaud

[Steven D'Aprano]

Re: pairs from a list

On Wed, 23 Jan 2008 10:39:25 -0800, George Sakkis wrote:

On Jan 23, 4:37 am, Steven D'Aprano
<ste...@REMOVE. THIS.cybersourc e.com.auwrote:

>On Tue, 22 Jan 2008 23:33:00 -0800, George Sakkis wrote:

As I mentioned already, I consider the seeking of the most efficient
solution a legitimate question, regardless of whether a "dumb"
solution is fast enough for an application. Call it a "don't be
sloppy" principle if you wish.

>>
>Sure, by why do you limit "efficient" and "don't be sloppy" to mean
>"write the fastest executing code you can, regardless of every other
>trade-off"?

>
I explicitly didn't limit sloppiness to inefficiency and mentioned it's
a tradeoff:

Of course you did, and I was being sloppy. The "you" was meant more as a
generic you than you yourself. Sorry for the confusion.

As for your other points, I think we're actually very much in agreement,
except for your tolerance of random posters asking what I believe is an
incoherent question: "what's the fastest way to do ...?". It seems to me
you're willing to give them the benefit of the doubt that they've done
their profiling and considered their trade-offs, or at the very worst are
asking from purely intellectual curiosity. Call me cynical if you like,
but I think that in the absence of any direct evidence supporting those
things, the most likely possibility is the opposite.



--
Steven

[Steven D'Aprano]

Re: pairs from a list

On Wed, 23 Jan 2008 11:06:44 -0800, George Sakkis wrote:

On Jan 23, 1:30 pm, Paddy <paddy3...@goog lemail.comwrote :
>

>I've heard quality expressed as "meeting requirements", which I think
>is apt. Falling short of requirements everyone knows doesn't give a
>quality result, but equally 'exceeding' requirements also detracts from
>quality (as does not knowing your requirements). It is good to learn
>optimization techniques, which may be part of what you are saying, but
>part of that is learning when it pays to apply them and/or search for
>them; and when it does not.

>
The OP wanted an answer to a simple question, not a lecture on good
software engineering principles.

(1) It isn't a simple question. There were at least five alternatives,
one of which would have been "fastest" except it failed the correctness
test. The OP went on to ask:

"I suppose my question should have been, is there an obviously faster way?
Anyway, of the four ways below, the first is substantially fastest.
[Note: actually it wasn't.] Is there an obvious reason why?"

Asking *why* something is faster is very different from asking *which* is
faster. I don't believe anyone actually answered that "why" question.

So, for the record, here's my attempt at an answer:

No, there is no "obvious" reason why one solution should be faster than
another. But perhaps the two most general rules of thumb are:

* the more work you can push into built-ins written in C, and the least
in slow code written in Python, the faster;

* lazy iterators are often (but not always) faster than building the
entire list all at once.



Other than that, the details of why one particular technique is faster
than another depends on the implementation of each, and that's not
obvious.



(2) What the OP wanted and what he needed are not necessarily the same.
Answering the OP's direct question is like giving him a fish -- he'll be
hungry tomorrow. Teaching him good engineering principles is like
teaching him to fish.

(3) This is Usenet, and the advice is free. Sometimes you get more than
you expected, sometimes less. Regardless of what the OP wanted, the
thread will go where the thread will go. The discussions of software
engineering were mostly in response to you, not the OP.



--
Steven