473,686 Members | 3,147 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

reduce() anomaly?

This seems like it ought to work, according to the
description of reduce(), but it doesn't. Is this
a bug, or am I missing something?

Python 2.3.2 (#1, Oct 20 2003, 01:04:35)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright" , "credits" or "license" for more information.
d1 = {'a':1}
d2 = {'b':2}
d3 = {'c':3}
l = [d1, d2, d3]
d4 = reduce(lambda x, y: x.update(y), l) Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 1, in <lambda>
AttributeError: 'NoneType' object has no attribute 'update' d4 = reduce(lambda x, y: x.update(y), l, {})

Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 1, in <lambda>
AttributeError: 'NoneType' object has no attribute 'update'

- Steve.
Jul 18 '05
226 12567
On 9 Nov 2003 22:40:57 GMT, bo**@oz.net (Bengt Richter) wrote:

[ackerman function generates very long integers]
Is there a fast formula for computing results, ignoring the representation problem?


This seems to be an easy way to generate them faster:

http://www.kosara.net/thoughts/ackermann.html

... back to the topic of this thread ...

From what I get of the main discussion (recursion vs iteration) it is
reasonable to not make a distinction based on the type of algorithm
but to only look at the order in which the nodes of the search space
are visited. It seems possible to turn recursive functions into
iterative ones by pushing and popping a stack of argument values.

This opens up possibilities of continuing from arbitrary positions of
the stack instead of just by pushing and popping ...

Anton
Jul 18 '05 #41
Alex Martelli wrote:
P. S. I've seen a lot of talk about removing old features from Python,
or specifically old built-ins, because of bloat. Does this "bloat"
reduce performance, or does it refer to the extra burden on someone
learning the language or reading someone else's code?

A slightly larger memory footprint, and larger built-ins dictionaries,
can only reduce runtime performance very marginally. The "cognitive
burden" of having built-ins that "don't carry their weight", on the
other hand, is considered an issue *in Python*, because it doesn't fit
in with Python's general philosophy and worldview. Python is meant to
be a LEAN language (with a not-lean standard library of modules that
are specifically imported when needed); certain "legacy" features are
sub-optimal (and best removed, when the strict constraint of backwards
compatibility can be relaxed) because they interfere with that (and
built-ins are close enough to "the core language" that they _do_ need
to be weighed severely in terms of "how often will they be useful").


Thanks, that's what I was trying to understand.

David

Jul 18 '05 #42
Thank you!
G-:

"Alex Martelli" <al***@aleax.it > wrote in message news:%R******** *********@news2 .tin.it...
| <skip>
Jul 18 '05 #43
"Alex Martelli" <al***@aleax.it > wrote in message
news:Bs******** *************** @news2.tin.it.. .
Francis Avila wrote:
[a reduce() clone]

[a long and thorough critique]


*Sigh* My only objective was to combine functional/recursive/iterative
programming styles into an olive branch to extend to both parties of this
silly war.

But oh well. Like I said, I never found a use for reduce, but alas, I am a
ham-fisted programmer entirely lacking in subtlety and art....
--
Francis Avila

Jul 18 '05 #44
Alex Martelli <al***@aleax.it > writes:
Anybody who can claim (without a smilie) that "sum is redundant with
reduce" has clearly lost all touch with reality.
*All* touch? My girlfriend still feels real to me when I touch
her....
"sum" accounts for about 80-90% of the uses of reduce found on large
existing codebases,
I have *never* used sum() (or a reduce() that ammounts to sum()). And
I use reduce() fairly often, in more or less the way that I described.
and even more when only _good_ uses of reduce are considered. "sum"
is way faster than "reduce(operato r.add, ..." -- and the advantage
in speed *AND* simplicity
I don't care about speed all that much when using Python. If I did, I
probably wouldn't be using Python. And to me, "simple" means
providing a small number of orthogonal features that combine easily,
rather than a lot of special purpose features, that all have to be
learned, remembered, and documented separately. sum() is a
special-purpose feature, while reduce() is a very general feature that
is very easily adapted to a myriad of situations. So what if 80-90%
of the uses of reduce in your experience is to support sum()? That's
not my experience, and even if it were, if sum() is used a lot, then
10-20% of that is still a lot. max(), like sum() also has a built-in
reduce. So the current approach for the future of Python seems to be
to build reduce() into everything that might need it? I'd prefer to
see reduce() taken out of sum() and out of max() and then no one needs
to document or learn that sum() and max() duplicate the functionality
of reduce(). Just learn, remember, and document one thing, and you're
all set.
grows even more when one considers how
often that typical reduce is miscoded as "reduce(lam bda x, y: x+y,
..." or "reduce(int.__a dd__, ..." and the like.
People who do this, no doubt, are more interested in coding than
wading through a big manual to figure out to make use of Python's
idiosyncracitie s to get their code to run as fast as possible in this
one particular implementation of Python.

Such people are surely not going to want to wade through the manual to
find sum().
The complications of going to a higher-order function and learning about
module operator "pay off" in a SLOWDOWN compared to elementary code...!
All of 3.4% according to your calculations. I'm not losing any sleep
over it.

Learning about module operator is not a chore, since I'd want to know
how to access these operators anyway.

Higher order functions are not complicated -- they are beautiful and
elegant.
The "fancy" ways reduce is often coded slow things down further by about
two times. This is clearly unacceptable.
There's nothing fancy about reduce() -- it's taught in every CS 101
class!
And the right solution is, quite obviously: [alex@lancelot test]$ timeit.py -c 'sum(xrange(999 ))'
10000 loops, best of 3: 129 usec per loop
Why? Because it saves having to type "operator.add," ? Because it's a
bit faster? Who cares about either one of these things. Certainly
not I.
giving speed, simplicity, and code that is clean, high-level, concise, and
immediately obvious to any reader or maintainer.
reduce() is immediately obvious to anyone who has ever taken CS
101. sum() is going in the direction of Perl, where there's a separate
idiomatic feature for everything that anyone might ever want to do.

I like Python because it is a very simple, generic, easy-to-learn
programming language, where I didn't have to learn much of anything
anything new. It was just like all the other myriad of programming
languages I have programmed in, only less cluttered than most, and
"light-weight" in its implementation and accessibility.

I having nothing against learning new stuff, by the way, but when I
want to learn new stuff, I'm not particularly interested in the
idiosyncrasies of Python -- I'd spend my effort learning something a
bit more exotic, like OCaml, or Haskell, that might stretch my brain a
bit. Learning a bunch of idiosyncratic detail is just tedious. This
is one of the most important reasons that Perl sucks so badly.
The paladins of reduce don't help their case by posting reduce "use
cases" that are complicated and rarely optimal:
def longer(x, y):
if len(y) > len(x): return y
else: return x def longest(seq):
return reduce(longer, seq) print longest(("abc", "yumyum!", "hello", "goodbye", "?"))


There's nothing complicated about my example. It's the epitome of
clarity and elegance.
In 2.4, the much simpler expression:
list.sorted(seq , key=len)[-1]
is about 3 times faster on a typical long seq (seq=map(str, xrange(2000)).
There's nothing simpler about that (in fact, conceptually, it's much
more complex) and it's only faster because of Python implementation
details. In most languages, or an alternate implementation of Python,
sorting a list would typically be significantly slower than a linear
search on it.
We still don't have (in the current pre-alpha 2.4) the "one obvious way",
max(seq, key=len), because max & other functions haven't yet been upgraded
to take the optional parameter key= as lists' sort and sorted methods, but
I trust they will be.
More annoying bloat. Instead of pumping up max() with bloat, tell
people to use reduce(). It's already there and simple and elegant.
And if one doesn't care for the concision of these new idioms, the most
elementary programming is still best: [alex@lancelot test]$ timeit.py -c -s'xs=map(str,xr ange(2000))' -s'''
def longest(seq):
seq=iter(seq)
best = seq.next()
blen = len(best)
for item in seq:
ilen = len(item)
if ilen>blen:
best = item
blen = ilen
return best
''' 'longest(xs)' 1000 loops, best of 3: 980 usec per loop


That's supposed to be best? It would take me 100 times as long to
figure out that code.
Once again, reduce proves to be an "attractive nuisance":
With the emphasis on "attractive ". It results in easy-to-read, easy
to remember coding techniques.
Higher order programming, such as the "max(seq, key=len)" which I
hope will make it into 2.4, is of course way simpler, faster, and
more concise -- but the "neither fish nor fowl" level at which most
uses of reduce fall just doesn't cut it, IMHO.
Except for that I'd never use it because I'd never even know it was
there because I prefer to spend my time writing software than wading
through manuals.
And btw, if one wants concision rather than speed, even in 2.3, the
typical DSU-like idiom:
def longest(seq):
aux = [ (len(x), -i, x) for i, x in enumerate(seq) ]
return max(aux)[-1]
still handily beats the reduce-coded alternative (even though
having the len= parameter instead of explicit decoration will
of course make it even smoother, simpler, and faster, in 2.4).


The above is particularly ugly.

|>oug
Jul 18 '05 #45
In article <vr************ @corp.supernews .com>, Francis Avila
<fr***********@ yahoo.com> writes
"Alex Martelli" <al***@aleax.it > wrote in message
news:Bs******* *************** *@news2.tin.it. ..
Francis Avila wrote:
[a reduce() clone]

[a long and thorough critique]


*Sigh* My only objective was to combine functional/recursive/iterative
programming styles into an olive branch to extend to both parties of this
silly war.

But oh well. Like I said, I never found a use for reduce, but alas, I am a
ham-fisted programmer entirely lacking in subtlety and art....
--
Francis Avila

This whole thread is reminiscent of vi vs emacs or an os war or similar.
It's a pity that people with a preferred style should be so dogmatic
that they want to remove language features to prevent others using them.

The whole 'only one way to do it' concept is almost certainly wrong.
There should be maximal freedom to express algorithms. As others have
stated min, max,... sum et al are useful specialisations , but because
they cover 99% of the space doesn't mean that reduce is redundant.
-Eliminate reducespeak and control the future-ly yrs-
Robin Becker
Jul 18 '05 #46
Robin Becker wrote:
...
This whole thread is reminiscent of vi vs emacs or an os war or similar.
It's a pity that people with a preferred style should be so dogmatic
that they want to remove language features to prevent others using them.
Python's essence is simplicity and uniformity. Having extra features
in the language and built-ins runs directly counter to that.

The whole 'only one way to do it' concept is almost certainly wrong.
Bingo! You disagree with the keystone of Python's philosophy. Every
other disagreement, quite consequently, follows from this one.

The world is *chock full* of languages designed with the philosophy
of "the more, the merrier". Why can't you let us have just _*ONE*_
higher-level language designed with full appreciation for "the spirit
of C" (as per the C standard's Rationale) in its key principles:

"""
(c) Keep the language small and simple.
(d) Provide only one way to do an operation.
"""

Maybe "the spirit of C" is as wrong as you claim it is. Personally,
I _cherish_ it, and in Python I found a language that cherishes it
just as much, while working at a much higher semantic level and thus
affording me vastly higher productivity. I will not stand idly by,
and let you or anybody else attack its foundations and thus try to
destroy its key strengths, without a fight.

There should be maximal freedom to express algorithms. As others have


Want "maximal freedom to express algorithms"? You can choose among
a BAZILLION languages designed according to your philosophy -- even
sticking just to higher-level languages with dynamic typing and
generally infix/algoloid syntax, Perl is the obvious example, and if
you just can't stand its core syntax, in full respect of this
"maximal freedom" principle, you can of course change it, too -- see
http://www.csse.monash.edu.au/~damia...Perligata.html and
revel in that _truly_ maximal freedom. Or, for a language that's
somewhat in-between, but still philosophically accepts the "maximal
freedom" tenet for which you crave, try Ruby -- if I _did_ want such
freedom, then Ruby is what I'd most likely use.

But can't you let us have *ONE* language that's designed according
to the concept you consider "almost certainly wrong"?! Why do YOU
use this language, even while you condemn its foundation and try to
undermine them, rather than using any one of the myriad that already
DO follow your philosophy?!

Trying to make Python into (e.g.) a Ruby with slightly different
cosmetics and "fine points" is truly absurd: if you want Ruby, you
know where to find it. Let Python stay Python, and leave those of
us who find ourselves best served by its design principles in peace!
Alex

Jul 18 '05 #47
In article <Os************ ******@news1.ti n.it>, Alex Martelli
<al***@aleax.it > writes
Robin Becker wrote:
...
This whole thread is reminiscent of vi vs emacs or an os war or similar.
It's a pity that people with a preferred style should be so dogmatic
that they want to remove language features to prevent others using them.
Python's essence is simplicity and uniformity. Having extra features
in the language and built-ins runs directly counter to that.


no disagreement, reduce is in line with that philosophy sum is a
shortcut and as others have said is less general.
The whole 'only one way to do it' concept is almost certainly wrong.
Bingo! You disagree with the keystone of Python's philosophy. Every
other disagreement, quite consequently, follows from this one.


not so, I agree that there ought to be at least one way to do it.
Want "maximal freedom to express algorithms"? You can choose among
.... you may be right, but I object to attempts to restrict my existing
freedoms at the expense of stability of Python as a whole.
But can't you let us have *ONE* language that's designed according


I am not attempting to restrict anyone or change anyone's programming
style. I just prefer to have a stable language.
--
Robin Becker
Jul 18 '05 #48
On Tue, 11 Nov 2003 11:39:20 +0000, Robin Becker
<ro***@jessikat .fsnet.co.uk> wrote:
... you may be right, but I object to attempts to restrict my existing
freedoms at the expense of stability of Python as a whole.


To paraphrase a famous saying (at least in the context of US law), your
freedom ends where another person's maintenance headache begins.

Gary
Jul 18 '05 #49
Alex Martelli <al***@aleax.it > writes:
Robin Becker wrote:
The whole 'only one way to do it' concept is almost certainly wrong.

Bingo! You disagree with the keystone of Python's philosophy. Every
other disagreement, quite consequently, follows from this one.


The "only one way to do it" mantra is asinine. It's like saying that
because laissez faire capitalism (Perl) is obviously wrong that
communism (FP) is obviously right. The truth lies somewhere in the
middle.

The mantra should be "small, clean, simple, powerful, general,
elegant". This, however, does not imply "only one way to do it",
because power and generality often provide for multiple "right" ways
to flourish. In fact, trying to enforce that there be only "one way
to do it", will make your language bigger, messier, more complicated,
less powerful, less general, and uglier, as misguided souls rush to
remove powerful and general tools like reduce() from the language, and
fill it up with special-purpose tools like sum() and max().

People have written entire articles on how to do functional
programming in Python:

http://www-106.ibm.com/developerwork...ry/l-prog.html

You would castrate Python so that this is not possible? Then you
would diminish Python, by making it a less general, less elegant
language, that has become unsuitable as a language for teaching CS101,
and only suitable for teaching How Alex Martelli Says You Should
Program 101.

|>oug
Jul 18 '05 #50

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

181
8796
by: Tom Anderson | last post by:
Comrades, During our current discussion of the fate of functional constructs in python, someone brought up Guido's bull on the matter: http://www.artima.com/weblogs/viewpost.jsp?thread=98196 He says he's going to dispose of map, filter, reduce and lambda. He's going to give us product, any and all, though, which is nice of him.
16
2175
by: clintonG | last post by:
At design-time the application just decides to go boom claiming it can't find a dll. This occurs sporadically. Doing a simple edit in the HTML for example and then viewing the application has caused the application to go boom. Sometimes the page will compile and run using F5 and others not. So I do the web search tango looking around the blogs and the tuts and determine I should go into Temporary ASP.NET Files and delete the directory...
1
2794
by: mai | last post by:
Hi everyone, i'm trying to exhibit FIFO anomaly(page replacement algorithm),, I searched over 2000 random strings but i couldnt find any anomaly,, am i I doing it right?,, Please help,,,The following is the code,, #include <iostream> #include <string> #include <stdio.h> #include <stdlib.h> #include <ctime // For time()
7
3502
by: cnb | last post by:
This must be because of implementation right? Shouldn't reduce be faster since it iterates once over the list? doesnt sum first construct the list then sum it? ----------------------- reduce with named function: 37.9864357062 reduce with nested, named function: 39.4710288598 reduce with lambda: 39.2463927678 sum comprehension: 25.9530121845
0
8581
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9050
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
8932
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
8766
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
7598
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
5795
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
1
2944
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
2205
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
1933
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.