Cython alternative to #1825 #1828
Conversation
|
Thanks for giving it a shot :) I didn't go through the code in any detail so I can't judge the overhead of maintaining the cython version. @larsmans any opinion? |
|
LGTM! I didn't try a |
|
Yes, there are yellow lines: https://gist.github.com/kmike/bf9b3ef041427068fcc4 Some of them are function starts & ends (because they are Python functions); _viterbi has a lot of Python calls (it is just a vectorized version from #1825); work_buffer allocations are also Python. |
|
Fair enough, +1 for merge. |
|
I ran more tests, and Cython extension provides a nice speed gain (> 1.5x compared to numpy+python) for 20-state HMM.fit(); I'm leaning towards this PR now. |
|
great if you are happy with it :) |
|
Even the tests are significantly faster. Merged as 919951a. |
Here .fit and .eval should be about 10-20% faster than #1825 on large HMMs and several times faster on tiny HMMs. _decode_viterbi should be on par with #1825.
_logsum is not moved to _extmath in this pull request.
For the record: I slightly prefer #1825 because of simplicity, but if there are use cases for HMMs with small number of parameters but slow training, this PR should be preferred.