Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Brilliant or insane code?

stavros.io

Post reply on HN
Print view View original

81–90 of 114 posts

Re: Brilliant or insane code?

#81

Post by specialist »

impressive wrote: post #67
hartror wrote: post #17

This is in the zip documentation as the way of solving this problem. Sort of surprised the author didn't look up the documentation before writing what is otherwise a very good post. The left-to-right evaluation order of the iterables is guaranteed. This makes possible an idiom for clustering a data series into n-length groups using zip(*[iter(s)]*n). http://docs.python.org/2/library/functions.html#zip

Recently I was downvoted 2-3 times on S.O. for an answer that was claimed to be non-idiomatic. So, I cleaned it up, but it really irked me. What I had written was totally fine. It shouldn't have hurt anyone's eyes. It was direct. It was in-your-face. It was not magic. Reading this post brought back that feeling. If people don't understand a completely valid and terse way of coding something, sometimes instead of both…

claimed to be non-idiomatic

I write specialist-o-matic code. Lotsa DRY, composition, iterators, "fluent" APIs.

Makes me an unapologetically poor general purpose pair programming partner.

terse and clear at the same time

Concision is a virtue.

Re: Brilliant or insane code?

#82

Post by specialist »

chipsy wrote: post #76
impressive wrote: post #67

Earlier quoted context omitted.

Recently I was downvoted 2-3 times on S.O. for an answer that was claimed to be non-idiomatic. So, I cleaned it up, but it really irked me. What I had written was totally fine. It shouldn't have hurt anyone's eyes. It was direct. It was in-your-face. It was not magic. Reading this post brought back that feeling. If people don't understand a completely valid and terse way of coding something, sometimes instead of both…

I think the mentality can be extended to most code-reading. Don't get it by skimming? Must be crap code. I only got away from that when I changed my litmus test towards whether I could write on top of the codebase successfully, not how it looked. Today my only real point of judgment about the look of code is whether it's written in a style that increases average error rate. w/r to Python in particular, it has a histo…

style that increases average error rate

Errors per LOC is allegedly constant, across all languages.

I also consider the cost of change when designing things.

I once created an HL7 wrapper that was a marvelous thing of beauty. Fluent API, clever use of the type system. But no one could maintain it, including me. It had too much magic. So I scrapped it, went with a dumber implementation.

Re: Brilliant or insane code?

#83

Post by aidos »

jasallen wrote: post #55
scotty79 wrote: post #16

i = iter(array) return zip(i, i, i) There you go. All but neceessary magic gone with just one line more.

It is clearer, but uses a fixed number of arguments, so may be unsuitable for some applications.

The current function has the same restriction. In their case it's in the form of " * 3 ".

Re: Brilliant or insane code?

#85

Post by beambot »

davidp wrote: post #65

I made a few more interesting (to me) measurements. As always, you have to measure your performance with your actual input data to see what's "best". Test 1: Boring, small array of integers In [28]: arr = range(0, 300) In [29]: %timeit [(arr[3*x], arr[3*x+1], arr[3*x+2]) for x in range(len(arr)/3)] 10000 loops, best of 3: 27.2 us per loop In [30]: %timeit numpy.reshape(arr, (-1, 3)) 10000 loops, best of 3: 45.2 us pe…

Since you're looking at alternatives... you might as well include: zip( arr[0::3], arr[1::3], arr[2::3] ) It's pretty fast, especially if the array is pre-allocated rather than a generated iterator.

Re: Brilliant or insane code?

#86

Post by garethadams »

aidos wrote: post #83
jasallen wrote: post #55

Earlier quoted context omitted.

It is clearer, but uses a fixed number of arguments, so may be unsuitable for some applications.

The current function has the same restriction. In their case it's in the form of " * 3 ".

That `3` can be trivially replaced with a variable in a way that `(i, i, i)` cannot. But still, the refactoring of the iterator into a separate variable is the key step which reinforces that the same object is being passed 3 times

Re: Brilliant or insane code?

#87

Post by davidp »

loarake wrote: post #73
pudquick wrote: post #70

Earlier quoted context omitted.

A point of clarification here - numpy's reshape operation stays fast as long as the array is a numpy array. Which is exactly what the parent comment was all about - the author figured that the reason numpy was significantly faster was because it was accessing / working with the data in a different fashion. So, in order to test that theory, he converted the numpy.array into a normal python array before he proceeded to…

My reply was in response to the statement "numpy is two orders of magnitude faster here; it's evidently using a highly optimized internal codepath for random sequence generation", which is false, it's not because of highly optimized internal codepaths for random sequence generation, it's because the code produced a numpy array (or didn't have to do type conversion). But I agree, when using numpy to produce a timing c…

Thanks for your comments. I hope it didn't sound like I was negatively comparing numpy's array/sequence operations to anything. I know very little about numpy, and I assume that "real" numpy solutions don't look anything like what's being discussed here. I only included those measurements since the article's author did.

To clarify my points a bit, the optimizations I alluded to (in "highly optimized internal codepath") were meant to include things like using a generator, i.e. at no point is there an actual array of input random numbers. The fact that in numpy the 300-element "array" and the 3,000,000-element "array" had identical timings suggests exactly that; I disagree that it's an issue of internal representation, unless the concept of a numpy array subsumes the concept of a generator, in which case I think we're all saying the same thing.

That kind of optimization is only possible in this case because by the definition of randomness nobody could know what the values were until they were enumerated, so it's 100% transparent to use a generator. That's not how real-world data works, hence my forced-native-array measurement and pudquick's reply.

Re: Brilliant or insane code?

#88

Post by tambourine_man »

akavel wrote: post #51
hartror wrote: post #17

This is in the zip documentation as the way of solving this problem. Sort of surprised the author didn't look up the documentation before writing what is otherwise a very good post. The left-to-right evaluation order of the iterables is guaranteed. This makes possible an idiom for clustering a data series into n-length groups using zip(*[iter(s)]*n). http://docs.python.org/2/library/functions.html#zip

By the way, I was recently surprised by a similar pattern in linux, where you can do: (echo -e "one\ntwo\nthree\nfour") | paste -d, - - to get result of: one,two three,four by exploiting a similar trick, i.e. reading two times ('- -') from the same iterator (STDIN of 'paste')

No need for parentheses,

  echo -e "one\ntwo\nthree\nfour" | paste -d, - -
works just fine

Re: Brilliant or insane code?

#89

Post by rhizome »

specialist wrote: post #81
impressive wrote: post #67

Earlier quoted context omitted.

Recently I was downvoted 2-3 times on S.O. for an answer that was claimed to be non-idiomatic. So, I cleaned it up, but it really irked me. What I had written was totally fine. It shouldn't have hurt anyone's eyes. It was direct. It was in-your-face. It was not magic. Reading this post brought back that feeling. If people don't understand a completely valid and terse way of coding something, sometimes instead of both…

claimed to be non-idiomatic I write specialist-o-matic code. Lotsa DRY, composition, iterators, "fluent" APIs. Makes me an unapologetically poor general purpose pair programming partner. terse and clear at the same time Concision is a virtue.

Concision is a virtue.

Can be.

Post reply on HN