substituting list comprehensions for map()

Ben Finney <ben+> writes:

> J Kenneth King <> writes:
>
>> Steven D'Aprano <> writes:
>>
>> > from operator import add
>> > map(add, operandlist1, operandlist2)
>>
>> This is the best solution so far.
>
> Strange to say it's a solution, when it doesn't solve the stated
> problem: to replace use of ‘map()’ with a list comprehension.

Granted I admit this later in my post. It's not a solution to the OPs
request, but it is the best solution to such a case.

>
>> I understand the OP was asking for it, but list comprehensions aren't
>> the best solution in this case... it would just be line noise.
>
> I disagree; a list comprehension is often clearer than use of ‘map()’
> with a lambda form, and I find it to be so in this case.

The use of map expresses a value and implies the procedure by which it
is obtained.

The list comprehension expresses the procedure by which the value is
obtained.

Both have uses and in some cases a list comprehension is definitely
preferrable to a map operation.

However in this case the procedure by which we derive the value is not
important or even interesting. It is much more succinct to think of the
operation as a value and express it accordingly. There's no need to
clutter the mind with extra name bindings and iteration keywords. They
won't make our idea any more clear.

dot_product = map(mul, vec1, vec2)

vs

dot_product = [a * b for a, b in zip(vec1, vec2)]

It's very clear, at least to me, what a dot-product is in this case.
Adding in the loop construct and name bindings doesn't enhance my
understanding of what a dot-product is. I don't need to see the loop
construct at all in this case. A dot product is simply the
multiplication of each element in a vector sequence. It's more succinct
to simply think of the value rather then expressing the procedure to
construct that value.

This isn't a hammer issue. Not every problem is a nail.

J Kenneth King

On Tue, 03 Nov 2009 10:22:28 -0500, J Kenneth King wrote:

> However in this case the procedure by which we derive the value is not
> important or even interesting. It is much more succinct to think of the
> operation as a value and express it accordingly. There's no need to
> clutter the mind with extra name bindings and iteration keywords. They
> won't make our idea any more clear.
>
> dot_product = map(mul, vec1, vec2)
>
> vs
>
> dot_product = [a * b for a, b in zip(vec1, vec2)]
>
> It's very clear, at least to me, what a dot-product is in this case.

Except it's not.

The dot product of two vectors returns a scalar, not another vector:
http://en.wikipedia.org/wiki/Dot_product

So what you want is:

dot_product = sum(map(mul, vec1, vec2))



> Adding in the loop construct and name bindings doesn't enhance my
> understanding of what a dot-product is. I don't need to see the loop
> construct at all in this case. A dot product is simply the
> multiplication of each element in a vector sequence.

What you need is to define a function dot-product, and not hijack the
name for a local value. Then the function's implementation is irrelevant
to you: it could use a list comp, or could use map, it could use a for-
loop, a while loop, recursion, or black magic:

scalar = dot_product(vec1, vec2)


--
Steven

Steven D'Aprano

Steven D'Aprano wrote:
> On Tue, 03 Nov 2009 10:22:28 -0500, J Kenneth King wrote:

>> Adding in the loop construct and name bindings doesn't enhance my
>> understanding of what a dot-product is. I don't need to see the loop
>> construct at all in this case. A dot product is simply the
>> multiplication of each element in a vector sequence.
>
> What you need is to define a function dot-product, and not hijack the
> name for a local value. Then the function's implementation is irrelevant
> to you: it could use a list comp, or could use map, it could use a for-
> loop, a while loop, recursion, or black magic:
>
> scalar = dot_product(vec1, vec2)

Or use the appropriate libraries:

from numpy import dot

scalar = dot(vec1, vec2)

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

Robert Kern

On Tue, 03 Nov 2009 22:43:45 -0600, Robert Kern wrote:

> Steven D'Aprano wrote:
>> On Tue, 03 Nov 2009 10:22:28 -0500, J Kenneth King wrote:
>
>>> Adding in the loop construct and name bindings doesn't enhance my
>>> understanding of what a dot-product is. I don't need to see the loop
>>> construct at all in this case. A dot product is simply the
>>> multiplication of each element in a vector sequence.
>>
>> What you need is to define a function dot-product, and not hijack the
>> name for a local value. Then the function's implementation is
>> irrelevant to you: it could use a list comp, or could use map, it could
>> use a for- loop, a while loop, recursion, or black magic:
>>
>> scalar = dot_product(vec1, vec2)
>
> Or use the appropriate libraries:
>
> from numpy import dot
>
> scalar = dot(vec1, vec2)


Why would I want to use an already existing library that is fast, well-
written and well-supported, when I can toss together a nasty kludge
myself?



--
Steven

Steven D'Aprano

Steven D'Aprano wrote:
> On Tue, 03 Nov 2009 22:43:45 -0600, Robert Kern wrote:
>> Or use the appropriate libraries:
>>
>> from numpy import dot
>>
>> scalar = dot(vec1, vec2)
>
>
> Why would I want to use an already existing library that is fast, well-
> written and well-supported, when I can toss together a nasty kludge
> myself?

because you want to perform a dot-product on strings?

>>> dot_product(['a', 'b', 'c'], [2,3,4])
'aabbbcccc'

[grins, ducks and scampers away after the
sum-shouldn't-special-case-strings-with-an-error thread]

-tkc

Tim Chase

> My personal preference would be a link in each sub-paragraph in the official
> documentation to a wiki page devoted to that specific aspect of the Python
> language. A place were users could augment the documentation by providing
> sample code and by expanding out the documentation for those of us who don't
> live and breath Python in our sleep. Real Python coders would not click on
> the user wiki links and all of us newbies could communicate with each other.
> But until a place like that exists, perhaps Pyfora will get us part way
> there.
>

The PHP documentation has this feature: user comments right on the
same page (no link to a wiki, though). It's great, most of the best
usage practices that I have learned in that language came from the
user's comments, not from the official documentation itself.


--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il

Dotan Cohen

Steven D'Aprano <> writes:

> On Tue, 03 Nov 2009 10:22:28 -0500, J Kenneth King wrote:
>
>> However in this case the procedure by which we derive the value is not
>> important or even interesting. It is much more succinct to think of the
>> operation as a value and express it accordingly. There's no need to
>> clutter the mind with extra name bindings and iteration keywords. They
>> won't make our idea any more clear.
>>
>> dot_product = map(mul, vec1, vec2)
>>
>> vs
>>
>> dot_product = [a * b for a, b in zip(vec1, vec2)]
>>
>> It's very clear, at least to me, what a dot-product is in this case.
>
> Except it's not.
>
> The dot product of two vectors returns a scalar, not another vector:
> http://en.wikipedia.org/wiki/Dot_product
>
> So what you want is:
>
> dot_product = sum(map(mul, vec1, vec2))

Derh. Thanks for the catch. My bad.

>> Adding in the loop construct and name bindings doesn't enhance my
>> understanding of what a dot-product is. I don't need to see the loop
>> construct at all in this case. A dot product is simply the
>> multiplication of each element in a vector sequence.
>
> What you need is to define a function dot-product, and not hijack the
> name for a local value. Then the function's implementation is irrelevant
> to you: it could use a list comp, or could use map, it could use a for-
> loop, a while loop, recursion, or black magic:
>
> scalar = dot_product(vec1, vec2)

Even better.

But now I'm afraid the example is running away from the point.

So to summarize:

1. Extra name bindings and loop keywords aren't always easier to read.

2. Expressing what we want rather than how we get it is much more clear.

and (third dirty argument added)

3. List comprehensions leak their name bindings to the surrounding
scope.

Have a nice day.

J Kenneth King

On Wed, 04 Nov 2009 23:08:54 +1100, Ben Finney wrote:

> Steven D'Aprano <> writes:
>
>> On Tue, 03 Nov 2009 22:43:45 -0600, Robert Kern wrote:
>> > from numpy import dot
>> >
>> > scalar = dot(vec1, vec2)
>>
>> Why would I want to use an already existing library that is fast, well-
>> written and well-supported, when I can toss together a nasty kludge
>> myself?
>
> Because using that library will ensure you can't migrate to Python 3 any
> time soon?


Why would I want to migrate to Python 3 any time soon? 2.5 and 2.6 meet
my needs (so far), and the new features in Python 3 aren't especially
compelling to me. Particularly if migrating to 3 requires me to re-write
all the libraries, where's the advantage?



--
Steven

Steven D'Aprano

On Thu, 05 Nov 2009 13:27:09 +1100, Ben Finney wrote:

> Steven D'Aprano <> writes:
>
>> On Wed, 04 Nov 2009 23:08:54 +1100, Ben Finney wrote:
>>
>> > Steven D'Aprano <> writes:
>> >> Why would I want to use an already existing library that is fast,
>> >> well- written and well-supported, when I can toss together a nasty
>> >> kludge myself?
>> >
>> > Because using that library will ensure you can't migrate to Python 3
>> > any time soon?
>>
>> Why would I want to migrate to Python 3 any time soon?
>
> Sounds like you've answered the questions posed, then. Good for you!

I was actually only being *half* tongue in cheek, which is why I left out
the smiley.

On the python-dev list at the moment is a lot of discussion on why uptake
of Python 3.1 has been slower than hoped. But one of the things that
people haven't really discussed -- or at least that I haven't seen -- is
why one would prefer 3.1 over 2.5 or 2.6.

I've played around with 3.0, and I've read the What's New for 3.1 (and am
installing 3.1 now), and while the changes look nice, I'm not sure that
they're nice enough to deal with the pain of 2to3 migration.

So how about that, 3.1 fans? What are the most compelling reasons for you
that convinced you to change?


--
Steven

Steven D'Aprano

* Steven D'Aprano:
> On Thu, 05 Nov 2009 13:27:09 +1100, Ben Finney wrote:
>
>> Steven D'Aprano <> writes:
>>
>>> On Wed, 04 Nov 2009 23:08:54 +1100, Ben Finney wrote:
>>>
>>>> Steven D'Aprano <> writes:
>>>>> Why would I want to use an already existing library that is fast,
>>>>> well- written and well-supported, when I can toss together a nasty
>>>>> kludge myself?
>>>> Because using that library will ensure you can't migrate to Python 3
>>>> any time soon?
>>> Why would I want to migrate to Python 3 any time soon?
>> Sounds like you've answered the questions posed, then. Good for you!
>
> I was actually only being *half* tongue in cheek, which is why I left out
> the smiley.
>
> On the python-dev list at the moment is a lot of discussion on why uptake
> of Python 3.1 has been slower than hoped. But one of the things that
> people haven't really discussed -- or at least that I haven't seen -- is
> why one would prefer 3.1 over 2.5 or 2.6.
>
> I've played around with 3.0, and I've read the What's New for 3.1 (and am
> installing 3.1 now), and while the changes look nice, I'm not sure that
> they're nice enough to deal with the pain of 2to3 migration.
>
> So how about that, 3.1 fans? What are the most compelling reasons for you
> that convinced you to change?

Since I'm just learning Python and am an utter Python novice this might not
amount to much, but it's in the nature of language evolution that the new more
or less incompatible version *does* become the dominant one, and for new things
it's then a good idea to adopt the coming in future generally used version of
the language, instead of being left in a quagmire trying to catch up with new
versions of tools and libs suddenly not so compatible with the old code.

This happened with e.g. C++ standardization in 1998. The whole standard library
was revamped and put in a namespace, and old headers like [iostream.h] were
removed. And as with the Python "/" operator core language functionality was
changed: in C++98 'new' suddenly threw (Pythoneese raised) an exception instead
of returning 0 on failure, and templates were suddenly "two phase" with quite
different semantics, so that much old code didn't even compile, and when it did,
didn't work correctly.

But those who chose to stay behind paid and still for some pay the price, having
to use ages old tools and libs. One amusing or sad (depending one's point of
view) variant was where firms chose to get along with the language evolution,
tools etc., but still restrict themselves to not only pre-standard C++ but some
early 1980's version, not much more than "C with classes" or "better C". For
example, at Google they generally don't use C++ exceptions, presumably because
they have a large code base of non-exception-safe code. Still, assuming that's
the rationale, it would surprise me if they don't use exceptions in their new code.

This is perhaps an heretical view, that the new language version's advantages
don't matter so much as the fact that the new language version is incompatible,
viewing that incompatibility as a /reason/ to change.

But I think it's realistic; getting the advantages (such as with Python 3.x
improved efficiency for range etc., and thus also more clear notation) is just
an added bonus.


Cheers & hth.,

- Alf

Alf P. Steinbach