It wouldn't have occurred to me to do this a different way. Isn't this a very basic use of zip()?
Brilliant or insane code?
31–40 of 114 posts
Re: Brilliant or insane code?
#32Earlier quoted context omitted.
This crashed my computer (it's an infinite loop that needs too much memory, apparently), and there's a mistake (the i is not defined). Turns out that islice doesn't raise an IterationError, it just returns an empty list. Fixing the problems, it runs in 237 μsec per loop, around 23 times more than the zip version.
Haha. I feel very silly now. I was just about to respond with the same thing. while True: result = list(islice(iterator, 3)) if not result: break yield result
That's what I did, I edited my post above. It's around 23x slower, although I had to use a function invocation for %timeit as well, so it's probably a bit faster in practice.
Re: Brilliant or insane code?
#33Earlier quoted context omitted.
I'd be surprised if my way is slower. Any time you unpack into a function such as zip() python has to create an intermediary list to store all the results before calling the function.
Exactly, I would be very surprised if the zip version was faster. One of the first steps to optimization in python is moving everything you can to generators and using of itertools. The OP's question of is this genius or bad is clear in that regard: it is bad, due to not being the proper optimization direction, but it is interesting.
I would be very surprised if it weren't. The zip version has the hot path written in C, the other version has it written in Python with a bunch of exception handling/list assignment code, etc. The original method is just zip(iterator, iterator, iterator), which is probably as fast as anything can be.
Re: Brilliant or insane code?
#34It wouldn't have occurred to me to do this a different way. Isn't this a very basic use of zip()?
[deleted]
Re: Brilliant or insane code?
#35Insane, because it relies on the zip implementation detail. If you cared about a measly factor of 4 in performance you wouldn't be using python anyway.
It's not an implementation detail, the order is guaranteed by the spec.
Re: Brilliant or insane code?
#36Earlier quoted context omitted.
Haha. I feel very silly now. I was just about to respond with the same thing. while True: result = list(islice(iterator, 3)) if not result: break yield result
That's what I did, I edited my post above. It's around 23x slower, although I had to use a function invocation for %timeit as well, so it's probably a bit faster in practice.
One more for kicks:
n = iter(array).next
[(n(), n(), n()) for _ in xrange(len(array) / 3)]Re: Brilliant or insane code?
#37I'm glad Clojure has top-level support for this operation... it's quite flexible too, and the presence of partition-all makes it explicit what you should expect if the sequence doesn't evenly partition.
user=> (partition 3 [1 2 3 4 5 6])
((1 2 3) (4 5 6))
user=> (partition 3 [1 2 3 4 5 6 7])
((1 2 3) (4 5 6))
user=> (partition-all 3 [1 2 3 4 5 6 7])
((1 2 3) (4 5 6) (7))
user=> (partition 3 3 (repeat 0) [1 2 3 4 5 6 7])
((1 2 3) (4 5 6) (7 0 0))Re: Brilliant or insane code?
#38We all love short and fast. But this is definitely an interesting approach. I'd love to see similar approaches to problems if you guys can point out to some.
I would also, I love this sort of thing. How about: >>> some_boolean = False >>> ["Thing 1", "Thing 2"][some_boolean] "Thing 1"
Yeah, but unlike the hack in the article, the more readable version of that code,
"Thing 1" if some_boolean else "Thing 2"
Re: Brilliant or insane code?
#39We all love short and fast. But this is definitely an interesting approach. I'd love to see similar approaches to problems if you guys can point out to some.
I would also, I love this sort of thing. How about: >>> some_boolean = False >>> ["Thing 1", "Thing 2"][some_boolean] "Thing 1"
the problem with this expression is that it doesn't "short circuit". Both "Thing 1" and "Thing 2" (in this cases object, but the can be function calls) are evaluated before the "some_boolean" usage.
Re: Brilliant or insane code?
#40Insane, because it relies on the zip implementation detail. If you cared about a measly factor of 4 in performance you wouldn't be using python anyway.
Any developer can care about performance. And should never be mocked for achieving above 200% performance compared to an alternative implementation... Let alone 400% performance compared to the alternatives.