reduce() anomaly?

[Stephen C. Waterbury]

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.

[Ben Finney]

On 19 Nov 2003 17:20:10 -0800, Paul Rubin wrote:

"A.M. Kuchling" <am*@amk.ca> writes:

[the Unix command] uniq doesn't report an error if its input isn't
sorted.

Maybe it should. If its behavior on unsorted input isn't specified,
you shouldn't assume it will act in any particular way.

The specification on the man page for GNU uniq seems clear on this:

DESCRIPTION
Discard all but one of successive identical lines from INPUT
(or standard input), writing to OUTPUT (or standard output).

It doesn't care if the input is sorted or unsorted; it describes
behaviour on successive identical lines, not the total set of all lines.

--
\ "The Bermuda Triangle got tired of warm weather. It moved to |
`\ Alaska. Now Santa Claus is missing." -- Steven Wright |
_o__) |
Ben Finney <http://bignose.squidly .org/>

[Erik Max Francis]

Aahz wrote:

Huh?!?! uniq has always to my knowledge only worked on sorted input.
Reading the man page on two different systems confirms my knowledge.

uniq doesn't care whether the input is sorted or not. All it does is
collapse multiple consecutive duplicate lines into a single line. Using
uniq in conjunction with sort is certainly a common mode, but it's
hardly required.

--
Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \
\__/ There are no dull subjects. There are only dull writers.
-- H.L. Mencken

[Paul Rubin]

Ben Finney <bi************ ****@and-benfinney-does-too.id.au> writes:

The specification on the man page for GNU uniq seems clear on this:

DESCRIPTION
Discard all but one of successive identical lines from INPUT
(or standard input), writing to OUTPUT (or standard output).

It doesn't care if the input is sorted or unsorted; it describes
behaviour on successive identical lines, not the total set of all lines.

OK, that's reasonable behavior.

[Mel Wilson]

In article <sl************ *************** ****@iris.polar .local>,
Ben Finney <bi************ ****@and-benfinney-does-too.id.au> wrote:

On 19 Nov 2003 17:20:10 -0800, Paul Rubin wrote:

"A.M. Kuchling" <am*@amk.ca> writes:

[the Unix command] uniq doesn't report an error if its input isn't
sorted.

Maybe it should. If its behavior on unsorted input isn't specified,
you shouldn't assume it will act in any particular way.

The specification on the man page for GNU uniq seems clear on this:

DESCRIPTION
Discard all but one of successive identical lines from INPUT
(or standard input), writing to OUTPUT (or standard output).

It doesn't care if the input is sorted or unsorted; it describes
behaviour on successive identical lines, not the total set of all lines.

It doesn't care if the input is sorted ascending or
descending, and it doesn't go to a lot of extra trouble to
check whether the order is monotonic.

Regards. Mel.

[Andrew Dalke]

Me:

And I've used what can now be written as

unique_keys = dict.from_keys( lst).keys()

Paul Rubin: This from_keys operation must be something new, and consing up a
dictionary like that is a woeful amount of overhead. But I guess
it would do the job.

Hmm, I misspelled it -- should be 'fromkeys' without the underscore.
Got confused with 'has_key'....

It's a new class method for dict

fromkeys(...)
dict.fromkeys(S[,v]) -> New dict with keys from S and values equal to v.
v defaults to None.

I said 'what can now be written as' meaning that before the
class method I would write it as

d = {}
for x in lst:
d[x] = 1
unique_keys = d.keys()

I don't know what you mean by 'consing up a dictionary'
taking up a 'woeful amount of overhead'. It's a bit of overhead,
but not woefully so. (And what does 'consing' mean? It's
a Lisp thing, yes? A 'cons cell' is the first / rest pair?)

BTW, another option is

unique_keys = list(sets.Set(l st))

but I still haven't internalized the sets module enough to
remember it trippingly.

For the case where I want a list of unique keys and where
I don't care about the resulting order then either of these
should work nicely.

Andrew
da***@dalkescie ntific.com

[Paul Rubin]

"Andrew Dalke" <ad****@mindspr ing.com> writes:

I don't know what you mean by 'consing up a dictionary'
taking up a 'woeful amount of overhead'. It's a bit of overhead,
but not woefully so. (And what does 'consing' mean? It's
a Lisp thing, yes? A 'cons cell' is the first / rest pair?)
Sorry, yeah, Lisp jargon. A cons cell is a pair but "consing" has a
more generalized informal meaning of allocating any kind of storage on
the heap, which will have probably to be garbage collected later.
Consing up an object means building it up dynamically.

The way I usually uniq a list goes something like (untested):

def uniq(list):
p = 0
for i in xrange(1, len(list)):
if list[i] != list[p]:
p += 1
list[p] = list[i]
del list[p+1:]

So it just scans through the list once and then does a single del
operation.
BTW, another option is

unique_keys = list(sets.Set(l st))

but I still haven't internalized the sets module enough to
remember it trippingly.

Yes, more consing :)

[Terry Reedy]

"Paul Rubin" <http://ph****@NOSPAM.i nvalid> wrote in message
news:7x******** ****@ruckus.bro uhaha.com...

Sorry, yeah, Lisp jargon. A cons cell is a pair but "consing" has a
more generalized informal meaning of allocating any kind of storage on the heap, which will have probably to be garbage collected later.
Consing up an object means building it up dynamically.
This 'generalized informal' meaning is new to me also ;-).
The way I usually uniq a list goes something like (untested):

def uniq(list):
p = 0
for i in xrange(1, len(list)):
if list[i] != list[p]:
p += 1
list[p] = list[i]
del list[p+1:]

So it just scans through the list once and then does a single del
operation.

I believe this requires list to be sorted, generally O(nlogn) if not
already so, while hash solution (sets, dict) is O(n) (+O(n) temporary
space). So either method can be 'best' in particular situation.

Terry J. Reedy

[Curt]

Erik Max Francis <ma*@alcyone.co m> writes:

Aahz wrote:

Huh?!?! uniq has always to my knowledge only worked on sorted input.
Reading the man page on two different systems confirms my knowledge.

uniq doesn't care whether the input is sorted or not. All it does is
collapse multiple consecutive duplicate lines into a single line. Using
uniq in conjunction with sort is certainly a common mode, but it's
hardly required.

curty@einstein: ~$ less uniq.txt
flirty
curty
flirty
curty

curty@einstein: ~$ uniq uniq.txt
flirty
curty
flirty
curty

curty@einstein: ~$ sort uniq.txt | uniq
curty
flirty

Maybe my uniq is unique.

curty@einstein: ~$ man uniq

NAME
uniq - remove duplicate lines from a sorted file
******

[Curt]

Erik Max Francis <ma*@alcyone.co m> writes:

The tweak I made to your sample file wasn't sorted. It just had two
identical adjacent lines. The modified sample again was: max@oxygen:~/tmp% cat > uniq.txt
flirty
curty
curty
flirty
^D
max@oxygen:~/tmp% uniq uniq.txt
flirty
curty
flirty You don't really think the sequence [flirty, curty, curty, flirty] is
sorted, do you?

Well, you did do _something_ to the sample for which you fail to find
a more descriptive word than "tweak". I certainly do think that the
proper word for the modified sample is "sorted"; yes, you sorted the
file on the word "curty", by which I mean that you performed "an
operation that segregates items into groups according to a specified
criterion" (WordNet). You segregated the item "curty" into a group
and therefore sorted the file by what we will now refer to as the
"curty criterion". That you didn't apply the "flirty criterion" to
your sort (or simply apply an alphabetical criterion) does not
demonstrate anything other than your cleverly disguised reticence to
employ the "sort" command. ;-)

[Ben Finney]

On 21 Nov 2003 12:46:44 +0100, Curt wrote:

Erik Max Francis <ma*@alcyone.co m> writes:

You don't really think the sequence [flirty, curty, curty, flirty] is
sorted, do you?
Well, you did do _something_ to the sample for which you fail to find
a more descriptive word than "tweak".

He contrived an example that demonstrated his point. You seem to be
fascinated with finding some definition of "sort" that can be bent to
this.
I certainly do think that the
proper word for the modified sample is "sorted"; yes, you sorted the
file on the word "curty", by which I mean that you performed "an
operation that segregates items into groups according to a specified
criterion" (WordNet).

This is ridiculous.

What makes you think he applied "the curty criterion", presuming there
can be some meaningful definition of that? Why could he not, perhaps,
have "sorted" it based on the arrangement of monitor toys he could see?
Or on the output of /dev/random ?

Are you saying that *any* list which has had *any* concievable criterion
applied to its generation, must therefore have been "sorted"?
None of this is the case.

The contrived example showed that 'uniq' *does* have an effect on a list
which has not been sorted (i.e. not sorted into the default order one
would assume when hearing the term "sorted", i.e. alphanumeric
ascending).

Writhing to attempt to force the term "sorted" to apply to an unsorted
list is rather psychotic.

--
\ "Any sufficiently advanced bug is indistinguishab le from a |
`\ feature." -- Rich Kulawiec |
_o__) |
Ben Finney <http://bignose.squidly .org/>