3 ms·
I like Numba, but it's sometimes jarring writing C-like code in a language which almost explicitly advises against it. Once you get into the habit of "FOR LOOP
by joshvm 11y ago
I like Numba, but it's sometimes jarring writing C-like code in a language which almost explicitly advises against it. Once you get into the habit of "FOR LOOP BAD" it's difficult to get out of!
It's interesting seeing what the effect of Big-O is. Once you introduce a logarithmic solution, it doesn't really matter that you're using Python because it's asymptotically so much better than the n^2 brute force approach. Nearest neighbour is a particularly nice demonstration of this, because it's an algorithm which is frequently used in realtime and obviously you don't want a performance hit of 2 seconds for every query!
Note Numpy has a builtin np.radians() which is a little cleaner than a one value look up table.
In [2]: %timeit np.random.random((10000))*3.14
1000 loops, best of 3: 245 µs per loop
In [3]: %timeit np.radians(np.random.random((10000)))
1000 loops, best of 3: 262 µs per loop
- gh02t 11y agoYeah I've started using Haskell a lot lately, which doesn't really do for loops per se. It was pretty natural to use `map` though because I was plenty used to Numpy style (ok really it's originally APL style but Numpy is where I picked it up). Numba is pretty nifty for things that are unnatural in this style, where an algorithm is better expressed in an index-dependent style, like e.g. a numerical ODE solver. Sometimes you can get around it with tricks like convolution, but not always.