O(n) :-P speedy solution for Non-unique Elements by veky - python coding challenges

Enable Javascript in your browser and then refresh this page, for a much enhanced experience.

O(n) :-P solution in Speedy category for Non-unique Elements by veky

def checkio(data):
    from collections import Counter
    nonunique = Counter(data) - Counter(set(data))
    return [x for x in data if x in nonunique]

Nov. 7, 2013

Comments:

veky on Nov. 12, 2013, 9:01 p.m.
For people with a low complexity class obsession (you know who you are;).

kermit666 on Nov. 13, 2013, 4:03 p.m.
<pre class='brush: python'> nonunique = Counter(data) - Counter(set(data)) </pre> Nice one. Didn't know about the Counter class before.

veky on Nov. 13, 2013, 4:12 p.m.
I know I have achieved my purpose when a three liner teaches somebody something new. :-)

wind on Nov. 21, 2013, 10:50 a.m.
looks like we can do or effective or short. But never both?

veky on Nov. 21, 2013, 10:53 a.m.
Depends on your expectations. This isn't short enough for you? :-)

wind on Nov. 21, 2013, 10:55 a.m.
It looks longer then <pre class='brush: python'>checkio=lambda d:[x for x in d if d.count(x)>1] </pre> ( your solution too )

veky on Nov. 21, 2013, 10:56 a.m.
Of course. If you haven't seen that one before, I bet you'd consider this one reasonably short. :-) That's why I said it depends on expectations. ( yes, I remember my own solutions :)

wind on Nov. 21, 2013, 11 a.m.
<blockquote> If you haven't seen that one before, I bet you'd consider this one reasonably short. :-) </blockquote> 100%

veky on Nov. 21, 2013, 11 a.m.
Also, "never" is really too strong a word. See this: <a href="http://www.checkio.org/mission/mathematically-lucky-tickets/publications/veky/python-3/comprehend/">http://www.checkio.org/mission/mathematically-lucky-tickets/publications/veky/python-3/comprehend/</a> Despite many tries to make longer and faster solutions, it still holds the throne as far as I know. ;-)

ethan.benjamin on Nov. 25, 2013, 12:11 a.m.
Very intuitive and nice. One minor improvement: [x for x in data if x in nonunique] could simply be list(nonunique).

veky on Nov. 25, 2013, 6:39 a.m.
No, it couldn't. Read the task again. <blockquote> "When solving this task, do not change the order of the list." </blockquote>

johnmulder29 on Aug. 7, 2015, 2:02 a.m.
I missed that in the directions... good call.

redteer on Nov. 25, 2013, 1:36 a.m.
Very nice

tristan.heuer_08da40cd57a343db on Dec. 11, 2013, 1:51 a.m.
I personally prefer my solution. Is my solution not pythonic or simply slow?

veky on Dec. 11, 2013, 7:07 a.m.
You have the right to prefer your solution. It's a perfectly obvious solution. :-) It is, however, algorithmically slower (O(n^2), since you have to pass list once for every element), and not quite pythonic since that coding pattern is clearer expressed as a list comprehension. Those things are not seriously impacting your code, of course.

DiZ on Dec. 11, 2013, 12:10 p.m.
Well, your solution is O(n) but need unnecessary treatment, I think. At least, why do you make 2 Counters? May I suggest this following, very similar to yours but with less memory used: <pre class='brush: python'>def checkio(data): from collections import Counter count = Counter(data) return [n for n in data if count[n] > 1] </pre>

veky on Dec. 11, 2013, 4:15 p.m.
That's why ":-P" is there. Algorithmic complexity class is one thing. Concrete execution is quite another. Multiplicative constants are really negligible almost always, especially when talking about memory, and when the constant is less than 2, I say you're nitpicking. Do you also wish to criticize authors of C++ STL, who treat constant of 2 when it comes to memory as completely transparent (see for example std::vector implementation). No, I think your problem is not memory usage. It's probably thinking "one Counter is better than two". But it isn't. If I already imported it, and reader of my code must know about it, why not use it twice if it simplifies the code?

DiZ on Dec. 12, 2013, 2:26 p.m.
I admit that a multiplicative constant, especially so small, is completely negligible for memory use. I think that notion of simplicity is completely subjective: for example, in my opinion, filtering input - as it is stated in problem description (count[n] > 1) - is easier to understand. My answer is here to complete yours and invite the reader to think about this kind of problem. Let's take a look at complexity of the algorithm: you need to read the text a second time with set(data) and you need to read alphabet a second time with Counter() - Counter(). This additional cost can be seen on relatively small texts (about 700-1000 kB). Although it is not main objective of this exercise, it is relevant to underline it.

riverprawn on Sept. 23, 2023, 12:07 p.m.
For a `data` with only unique elements, your solution has to iterate through the `data` 5 times. While his will only requires 2 times. So his is about three times as fast as yours. However, if you replaced the third line of yours with: ```python nonunique = set(k for k, v in Counter(a).items() if v > 1) ``` Then your solution will be as fast as his for an all-unique-element list, and faster than his for a list like `[0] * (10**7)`

riverprawn on Sept. 23, 2023, 12:13 p.m.
For a `data` with only unique elements, your solution has to iterate through the `data` 5 times. While his will only requires 2 times. So his is about three times as fast as yours. However, if you replaced the third line of yours with: ```python nonunique = set(k for k, v in Counter(a).items() if v > 1) ``` Then your solution will be as fast as his for an all-unique-element list, and faster than his for a list like `[0] * (10**7)`

janorel on Jan. 22, 2014, 10:43 p.m.
This is O(n^2) due to: [x for x in data if x in nonunique]

abe.dillon on Jan. 30, 2015, 7:58 a.m.
Accessing a hash table (aka dict) has a time complexity of O(1). This solution is O(n). You can verify that by timing the solution. [1] %timeit checkio(list(range(10**4))+[0]) 2.15 ms [2] %timeit checkio(list(range(10**5))+[0]) 28.2 ms [3] %timeit checkio(list(range(10**6))+[0]) 301 ms [4] %timeit checkio(list(range(10**7))+[0]) 2.83 seconds (These were the numbers I go from running these tests in ipython)

veky on Jan. 30, 2015, 11:07 a.m.
Read also my comment <a href="http://www.checkio.org/mission/non-unique-elements/publications/veky/python-3/on-p/share/d224da8d8591b889c30fad99b962c061/#comment-8564">below</a>. ;-)

janorel on Jan. 22, 2014, 11:08 p.m.
This is O(n*log(n)) due to: [x for x in data if x in nonunique]

veky on Jan. 23, 2014, 7:38 a.m.
This doesn't make sense. You could have said it's O(n^2) if you're being pessimistic, but there's no reasonable interpretation in which it is O(nlogn). Python dicts are not balanced trees, they are hash tables. See <a href="https://wiki.python.org/moin/TimeComplexity">https://wiki.python.org/moin/TimeComplexity</a> . Also see <a href="http://stackoverflow.com/questions/1963507/time-complexity-of-accessing-a-python-dict">http://stackoverflow.com/questions/1963507/time-complexity-of-accessing-a-python-dict</a> for a broader perspective.

janorel on Jan. 23, 2014, 8:03 a.m.
Right O(n*n) is amortized complexity.

veky on Jan. 23, 2014, 8:09 a.m.
"Amortized" is really misleading here. It's "amortized worst case", which is equal to just "worst case" here. Even better said, "worst of worst cases". If you have such bad luck, you shouldn't be programming at all. :-D Seriously, see <a href="http://stackoverflow.com/a/1964422">http://stackoverflow.com/a/1964422</a> answer (A1 part). It would practically be considered a bug in Python if you actually managed to achieve that (although it's mathematically possible, of course).

StefanPochmann on Dec. 22, 2021, 7:46 a.m.
Managed to achieve making your solution take quadratic time? That's easy.

veky on Dec. 22, 2021, 7:56 a.m.
Have you tried (taking into account hash randomization)?

StefanPochmann on Dec. 22, 2021, 7:59 a.m.
Yes, I have. And int hashes aren't randomized.

StefanPochmann on Dec. 22, 2021, 8:32 a.m.
I can show it if you want. Let me know whether you prefer obvious or obfuscated :-)

veky on Dec. 22, 2021, 8:49 a.m.
<blockquote> int hashes aren't randomized </blockquote> Ah, that's what I missed. 😔😄 Anyway, a demo would be nice. Obvious, since it could be of value to others here.

StefanPochmann on Dec. 22, 2021, 11:01 a.m.
Ok, here it is. With 4000 numbers it takes me about 1 second, with 8000 about 4 seconds. ``` from sys import hash_info from timeit import timeit def checkio(data): from collections import Counter nonunique = Counter(data) - Counter(set(data)) return [x for x in data if x in nonunique] for n in 4000, 8000: data = [hashinfo.modulus * i for i in range(n)] print(n, timeit(lambda: checkio(data), number=1)) ``` The <a href="https://docs.python.org/3/library/stdtypes.html#numeric-hash">hash value</a> of a nonnegative int `x` is `x % hashinfo.modulus`, so while all elements in my `data` differ, they all have the same hash value `0`. Collisions all the way down. The <a href="https://docs.python.org/3/library/sys.html#sys.hash_info">`hash_info.modulus`</a> value is usually `2**61 - 1`, so not tiny, but also not so unreasonably large that they and their operations can't be considered O(1). (Just saying in case anyone thinks the reason your solution is slow on these numbers is that the numbers are gigantic. Although the quadrupling of the time when doubling the number of elements already indicates quadratic runtime.)

veky on Dec. 22, 2021, 11:21 a.m.
Yeah, it is obvious but thanks for writing it out anyway. :-) It just shows how half-solutions are sometimes worse than no solutions. I just thought "Python has smart dicts and randomizes hashes, what could possibly go wrong" - at least before randhash I would be aware of the problem. :-]

StefanPochmann on Dec. 22, 2021, 11:30 a.m.
The obfuscated "puzzle" version btw would've been to use 1816789976097113843994684875811475351 as multiplier. That's the `hash_info.modulus` prime multiplied with another equally large prime to hide the bit pattern and make factorization harder for people who don't know fast factorizers. And of course I wouldn't have explained anything. Went the complete opposite then for your "value to everyone" reason.

veky on Dec. 22, 2021, 11:32 a.m.
Well, to anyone who knows how python int hash works (which ironically includes me, though I thought I didn't know that anymore since they "changed" it:)) it's not so hard. You don't need fast factorizers when you know (or can guess) one factor. :-] But yeah, sorry for making you write something tidy. ;-DD

StefanPochmann on Dec. 22, 2021, 11:40 a.m.
I suspect most people don't know it. I myself had never looked it up until a few months ago. I had known for a long time that "small" ints hash to themselves, but didn't know what large ones do.

veky on Dec. 22, 2021, 11:59 a.m.
Well, if you ever wrote any hash function, you probably used % operator, didn't you? And "the simplest thing that could possibly work" is then obvious. Even Wikipedia says "One of the simplest and most common methods in practice is the modulo division method." :-)

StefanPochmann on Dec. 22, 2021, 2 p.m.
Yes, but the simplest thing might not be desirable. You yourself just complained about int hashing not be randomized. It could very well have been that hashes are 64-bit integers, that numbers smaller than that get hashed to themselves for speed reasons, and that numbers larger than that get some kind of randomization / bit scrambling.

veky on Dec. 22, 2021, 2:07 p.m.
Yes, but branches are expensive. 😔 And people who complain about the nonrandomness of hashes have equal (if not bigger) problems with nonrandomness of hashes of small ints, as with that of big ints. 😅

StefanPochmann on Dec. 22, 2021, 2:56 p.m.
Do they? Why? I for example was able to so easily cause those collisions only thanks to big ints. I'm not able to do that with small ints, i.e., in [0, modulus). So if just big ints were randomized, I wouldn't be able to do it at all. It might very well still be practically feasible, but I think it's at least much harder. Ok, I guess people seriously worrying about security are not worried about me, but about adversaries smarter and more determined, who might find it easy :-) About branches: I think most of the time you'd take the "small" branch. And if you do take the "large" branch frequently, you might likely be working with arbitrarily large numbers and take the "large" branch most of the time. Also, if I'm not mistaken, `%` is expensive as well (at that low level where branching plays a role).

StefanPochmann on Dec. 22, 2021, 3:04 p.m.
Forget that last sentence, I just remembered that it's a special prime and that the hashing code doesn't use `%`.

veky on Dec. 22, 2021, 3:29 p.m.
Well, your first argument boils down to "there are much fewer small numbers than big ones". :-D The point is, for the collision it doesn't really matter that the numbers are big, just that there are many to choose from, and them mostly being big is just a consequence. :-] And of course Python hash is not cryptographically secure hash, nor was it designed to be such. The point was not security, but performance.

StefanPochmann on Dec. 22, 2021, 4:58 p.m.
How does "there are much fewer" play a role there? For normal usage it's "performance", yes, but the collision attack that I think led to the string hash randomization is categorized as a <a href="https://bugs.python.org/issue13703">security issue</a>.

veky on Dec. 22, 2021, 8:03 p.m.
Well, if a set of numbers is big, there is a greater chance of collision, of course. You wouldn't get many collisions in [9**99..9**99+x], the same as in [0..x]. The important part is how big the set is, not how big its elements are. Security: well, yes, but that's just politics. We all know that if there is a way to frame something as fixing a security issue, it will be deployed at least an order of magnitude more quickly. :-P (If GIL was claimed to be a security hole, it would be dead and buried a long time ago.:)

StefanPochmann on Dec. 22, 2021, 9:06 p.m.
Hmm, I'm still not sure what you're talking about. You said my first argument boils down to it, are you talking about my argument that I couldn't do it with small ints? That's not really about them being small nor about them being not so many. What I meant is that those small ints all have different hashes, so it's impossible to create such complete collisions there like I did. Instead, I'd have to find collision paths in the dictionary, which does scramble the bits. That's a different problem, and pretty complicated if not impossible, partly due to the dict's overallocation.

veky on Dec. 22, 2021, 9:41 p.m.
Ok, let's go back. I said that if I complained about int hashing not being randomized, it's much more probable that I'd notice that on small integers, than on large ones. To that, you replied that you could more easily generate collisions on large numbers, but in fact the reason for that is not that they are large, just that there is a lot of them.

Jiyoqisv on June 4, 2014, 8 p.m.
can you explain why "-" between two Counter (is Dict) ?

Jiyoqisv on June 4, 2014, 8:06 p.m.
can you explain why "-" between two Counter (is Dict) is O(n) ?

veky on June 5, 2014, 5:47 a.m.
Well, you go through first one, seek keys in second one, and subtract. What is the problem? (lookup is average O(1).)

learningpro.dong on Aug. 29, 2014, 2:56 p.m.
WOW, I start to learn python today and your code encouraged me a lot!

veky on Aug. 29, 2014, 9:23 p.m.
I'm glad to help. :-)

vikulin on Sept. 25, 2014, 5:50 a.m.
isn't this solution faster? <pre class='brush: python'>def checkio(data): from collections import Counter c = Counter(data) return [x for x in data if c[x] > 1] </pre>

veky on Sept. 25, 2014, 3:08 p.m.
Might be. timeit. :-) Also, have you seen <a href="http://www.checkio.org/mission/non-unique-elements/publications/veky/python-3/on-p/#comment-7250">this comment</a>?

_Jok on Jan. 10, 2015, 4:44 a.m.
It's awesome

veky on Jan. 10, 2015, 8:01 a.m.
Thanks. :-)

ben.liyanage on Jan. 20, 2015, 9:19 p.m.
Does this perform better then building your own hash? Or is it more that is compact?

veky on Jan. 21, 2015, 9:45 a.m.
I'm not quite sure what are you proposing... surely you aren't going to write your own dict in Python (and if you did, it would probably be very slow:). If you just meant to ask if it's better to use a generic dict or a collections.Counter, surely it's better to use Counter, but that doesn't really have to do much with performance. Python is not written to be fast, it is written to be understood. And if you want a structure to tally the occurrences of items in your list, surely Counter is the way to do it. That being said, it is probably also faster, since the less you write, the less the interpreter has to chew on, and it's embarrassingly often the deciding factor. But this is at best of secondary importance.

oglop on Nov. 29, 2015, 7:17 p.m.
Thank you for introducing me to Counter! :) I'm very python and programming beginner.

veky on Nov. 30, 2015, 4:05 a.m.
No problem. Python has many batteries included. ;-)

dalluca on March 6, 2016, 8:11 p.m.
Hi Veki. As always, your code is full of starting points for new features understanding. I am a very beginner, so the following words are not meant to be a critique but only a question. I was wondering if it is really necessary to count how many times an item appears. Wouldn't it be faster and simpler to only check if it appears at least one more time in the list, without counting through all the list and then subtract 1 to the count of each item?

veky on March 7, 2016, 2:26 p.m.
You're completely correct when you say it's not necessary to keep track of how many times an item appears. My solution <a href="http://www.checkio.org/mission/non-unique-elements/publications/veky/python-3/two-bins/">Two bins</a> is made with exactly that purpose. (Too bad it's not better known, but you can help it with your thumbs.;) Where you're not correct (probably) is that it will be faster. Python is not a native language of a computer architecture, and everything implemented in C is much faster than equivalent thing written in Python. `collections.Counter` is written in C, and is very fast in doing what it does best: counting. "Two bins" has a Python loop over the argument in it, which is probably enough to make it slower. But you're welcome to timeit and prove me wrong... I have been wrong about Python performance before. ;-) [That is one interpretation of what you said. Another is that you think that going through the rest of the list for every element separately (until I find a duplicate) would be faster. And that's sad. :-P Just try to imagine what will happen on a thousand-item list, and you'll see why.:]

dalluca on March 8, 2016, 12:25 p.m.
I have done a test. I avareged the execution time of some implementations of this task on 100 random generated lists of integer numbers tooken in the interval [0,10^6] of lenght 10^6. The result <pre class='brush: python'>My solution: 1.182 s Your counter: 0.565 s Your 2Bits: 0.294 s </pre> seems to tell that the winner is 2BITS :-D I am only wondering why my solution is so much slower. PS: I did not include the solution with "list.count(element)" because it is really too slow.

dalluca on March 8, 2016, 12:51 p.m.
I have done a test. I avareged the execution time of some implementations of this task on 100 random generated lists of integer numbers tooken in the interval [0,10^6] of lenght 10^6. The result <pre class='brush: python'>My solution: 1.182 s Your counter: 0.565 s Your 2Bits: 0.294 s </pre> seems to tell that the winner is 2BITS :-D I am only wondering why <a href="http://www.checkio.org/mission/non-unique-elements/publications/dalluca/python-27/slicing/?ordering=newest">my solution</a> is so much slower. PS: I did not include the solution with "list.count(element)" because it is really too slow.

veky on March 8, 2016, 8:39 p.m.
Hm, that's interesting. Important thing is obviously that Counter solution loops two times through the whole data, and 2 bins only once. But still, 0.565/2 is too close to 0.296. I think the superfluous operation that Counter solution does, that really makes the difference, is that during -, it compares every result with 0 and deletes items that have 0 there. And a dict with lots of deletions is slow for checking containment, since the hash table never shrinks in memory. Why is your solution so much slower? That's exactly what I was referring to with "And that's sad" above. :-P Seriously, just try to imagine what happens when you have thousand items. You take the first item. Then you compare it to every other item. 999 comparisons (if it's not there) or around 500 of them on average (if it is). Then you take the second item. And you again compare it to every item after it. More 998 comparisons (if it's not there) or 499 (if it is). Then you take the third item. And again compare it to few hundred elements. You see the problem? Your algorithm is of quadratic complexity. Doubling the size of input multiplies its execution time by 4. It's just horrible. :-O

dalluca on March 9, 2016, 8:21 a.m.
Ok. But I make that comparison only once per non unique element, cause I keep track of already checked elements. Of course if I take the random numbers in the list in the interval [0,10^6] as I did in the test it is higly likely that I will make several comparisons, thus you're right. But if I take the elements in a smaller interval (let's tell [0,100], or even better [0,10]) the algorithm could result more interesting. Let's try it: thus, with random generated lists of lenght 10^6 with elements in the interval [0,10] we have <pre class='brush: python'>My solution: 0.4956 Your counter: 0.6040 Your 2Bits: 0.3132 </pre> but if I just go up to elements in [0,100] the result stops again on what I found in the preceding test. Your solutions are much more elegant and less depending on parameters too, but let me tell that my solution was a nice try please... :-D Thanks for sharing knowledges. It's time to study dictionaries and tuples now :-D Bye

veky on March 9, 2016, 11 a.m.
<blockquote> cause I keep track of already checked elements. </blockquote> Yes, but you're doing it wrong. :-P Probably because list is the only adequate datatype you know about, you suffer from a problem of "when all you have is a hammer, everything starts looking as a nail". How do you keep track of them? You put them in a list. And how do you see if you've already checked an element? Another searching through a list (`checked` this time) and comparing an element to all (or about half) of them. :-/ `set`s exist in Python for a reason. Go study them, IMO even before dicts and tuples.

dalluca on March 9, 2016, 2:48 p.m.
The proverb of the hammer is really nice... I will remember it!! :-D Anyway, you're completely right ... I will study it!! Thanks again.

StefanPochmann on June 22, 2017, 2:42 p.m.
<blockquote> `Counter` is written in C </blockquote> I don't think that's true, is it?

veky on June 22, 2017, 5:35 p.m.
Hm, interesting. Yes, you're right. For some reason, `deque`, `defaultdict` and `OrderedDict` are, but `Counter` isn't. Probably the criteria was just how much effort Raymond wanted to invest. :-)

StefanPochmann on June 22, 2017, 10:17 p.m.
Though apparently an important part of it is implemented in C: <a href="https://github.com/python/cpython/blob/3.6/Lib/collections/__init__.py#L464"><a href="https://github.com/python/cpython/blob/3.6/Lib/collections/__init__.py">https://github.com/python/cpython/blob/3.6/Lib/collections/__init__.py</a>#L464</a> <a href="https://github.com/python/cpython/blob/master/Modules/_collectionsmodule.c">https://github.com/python/cpython/blob/master/Modules/_collectionsmodule.c</a>#L2263 I'm confused by `OrderedDict`. It doesn't seem to have source code in `_collectionsmodule.c` like `deque` and `defaultdict` do, but it <a href="https://github.com/python/cpython/blob/master/Modules/_collectionsmodule.c#L2413">is mentioned there</a> and the `from _collections import OrderedDict` works. On the other hand, `inspect.getsource(collections.OrderedDict)` does show me Python code, just like `Counter` and unlike `deque` and `defaultdict` (which cause an error). Oh man, I like reading Python's Python sources, but I hate trying to read Python's C sources.

veky on June 23, 2017, 4:08 a.m.
Ah yes, that's probably what I was thinking about when I wrote that message. Thanks for going to the bottom of it. About OrderedDict: probably the reason was that it is the new kid on the block, until maybe a year ago it was written in Python. Probably the source is still there for backward compatibility. Where exactly is it implemented is a different question. :-) Yes, staring into the Python's soul feels impolite. And dirty. :-D

ljy95135 on April 10, 2016, 5:58 a.m.
awesome,using dict but now find Counter which can save the order

veky on April 11, 2016, 5:40 a.m.
No, Counter by itself doesn't save the order (but you can hybridize it with OrderedDict if you want to:). What saves the order here is the list comprehension, which loops over the original data.

ljy95135 on April 11, 2016, 5:51 a.m.
Oh,now I totally get it:). Thank you!

RubtsovAV on June 13, 2016, 12:03 p.m.
It's look like as 3*O(n) Counter(data) - O(n) Counter(set(data)) - O(n) And the cycle on last row - O(n) In total - 3*O(n)

veky on June 13, 2016, 7:23 p.m.
Either you're bigger troll than me, or you don't understand O-notation. :-| In short, 3*O(n) is also O(n).

RubtsovAV on June 15, 2016, 3:23 p.m.
I understand O-notation. Your solution is not fastest and I talking about it. The fastest solution is 2*O(n).

veky on June 15, 2016, 5:25 p.m.
"My solution" is not uniquely defined. Have you seen <a href="https://checkio.org/mission/non-unique-elements/publications/veky/python-3/two-bins/?ordering=most_voted">this one</a>?

santagada on Sept. 18, 2016, 3:47 p.m.
Although your solution if indeed O(n) it is twice as slow as: <pre class='brush: python'>c = Counter(data) return [x for x in data if c[x] > 1] </pre> and three times as slow as: <pre class='brush: python'>first = set() repeated = set() for x in data: if x in first: repeated.add(x) first.add(x) return [x for x in data if x in repeated] </pre> not that it matters for such a simple problem but someone might find it interesting.

veky on Sept. 18, 2016, 4:32 p.m.
That's why ":-P" is there. Many people consider algorithmic complexity as the only important thing. :-) About your last snippet, please look at <a href="https://py.checkio.org/mission/non-unique-elements/publications/veky/python-3/two-bins/">Two bins</a> (and <a href="https://py.checkio.org/mission/non-unique-elements/publications/veky/python-3/two-bins/share/e91b71411242053fb175004cb3e1b766/#comment-44259">this comment</a> if you're still not satisfied;).

zancas on Sept. 20, 2016, 2:13 a.m.
Nice!

veky on Sept. 20, 2016, 9:57 a.m.
Thanks! :-)

ryan.n.goodner on Nov. 12, 2016, 5:43 a.m.
Nice, this is the computer scientist answer.

veky on Nov. 12, 2016, 8:03 a.m.
:-D Yes. Especially the ":-P" part. ;-)

crazychemistry474 on May 13, 2018, 11:38 a.m.
Nice! I considered using dict and set. But I don't know subtraction is supported in dict. Haha.

veky on May 13, 2018, 12:38 p.m.
It isn't. :-P <pre class='brush: python'>>>> {} - {} TypeError </pre> But it is on Counters. ;-)

bsquare on Sept. 18, 2019, 9:14 a.m.
Interesting solution!

veky on Sept. 18, 2019, 9:14 a.m.
Now you're just being lazy. :-P

bsquare on Sept. 18, 2019, 9:16 a.m.
I'm afraid I didn't understand this one?

veky on Sept. 18, 2019, 9:17 a.m.
Al least before you tried to find some original compliment to say about my solutions. Posting the same "review" on two of them consecutively is just lazy. :-]

bsquare on Sept. 18, 2019, 9:19 a.m.
Ho! Right! Lazy matches, but I would word it 'lacking of time but still willing to notify I find the solution interesting' ;)

veky on Sept. 18, 2019, 9:21 a.m.
You can use thumbs for that, much simpler. :-P

DEADPOOL on Jan. 10, 2021, 2:14 p.m.
Wow

rybld2 on May 23, 2021, 11:51 a.m.
I don't know if this solution is particularly fast but how elegant it is! (thanks)

veky on May 23, 2021, 12:51 p.m.
I think I said everything in the comments above. ;-)

2dfsdfl on Aug. 18, 2021, 6:59 a.m.
goooooooooooooooooood

2dfsdfl on Aug. 18, 2021, 7 a.m.
gooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooood

dddiiirrr3 on Oct. 23, 2021, 6:47 p.m.
why are imports statements inside the function? It is not pythonic way and it violate PEP8.

veky on Oct. 23, 2021, 8 p.m.
Are you sure you want to discuss what's Pythonic with me? :-) And don't worry, I'm not going to submit this code to Python's standard library. :-P

viktor.chyrkin on Oct. 24, 2021, 3:59 p.m.
bro you chillin.

9Teen90Three on Dec. 21, 2021, 7:01 a.m.
Thank you. I found it valuable because of demonstration of Counter substraction.

Micheal_Yu on Feb. 13, 2022, 3:39 p.m.
XD

phongtt2 on May 11, 2022, 7:44 a.m.
Great. I didn't know that we can apply operator on Counter data type

veky on May 11, 2022, 10:58 a.m.
Sometimes it helps to read the documentation. :-)

darkfire518 on Jan. 24, 2023, 2:58 p.m.
I like this solution. Quite similar to mine in that I used sets. Except I didn't import Counter. And I didn't use list comprehension. Ok, it's not similar to mine at all actually.

veky on Jan. 24, 2023, 3 p.m.
😁

riverprawn on Sept. 23, 2023, 12:23 p.m.
If you replace the third line of your code with: ```python nonunique = set(k for k, v in Counter(a).items() if v > 1) ``` Then your solution will be as fast as the one suggested by others for a list of all unique elements. And ever faster than theirs for a list of all the same elements (for example `[0] * 10**7`).

a8696tk on March 1, 2024, 8:28 a.m.
perfect solution

veky on March 1, 2024, 8:48 a.m.
Have you seen two bins? 😁

a8696tk on March 1, 2024, 9 a.m.
This code creates just one Counter object and then uses it to define non-repeating elements. Here's how to optimize this code to only use one Counter object: <pre class='brush: python'>def checkio(data): from collections import Counter counts = Counter(data) return [x for x in data if counts[x] > 1] </pre> I would do this, but each version has a right to life)

veky on March 1, 2024, 9:30 a.m.
You're very weird. First you say the solution is perfect, then in literally next message you say how to optimize it. I'm not sure I follow. :]

List but not the least

0 %

You ClassRoom Demo is Ready With the new tool CheckiO ClassRoom, you will be able to analyze your students' progress, have your own leaderboard, change missions order on the map, and so on.