When I looked at the implementation of _calc_kkr I saw that there are 2 issues when it comes to speed:
the code is formulated in a mathematical sense which handles the two cases of odd and even in one loop:
integral = np.zeros(len(t))
interval = np.diff(x, prepend=x[1] - x[0])
odd_y, odd_x = t[1::2], x[1::2]
even_y, even_x = t[::2], x[::2]
for i, x_i in enumerate(x):
if i % 2 == 0:
integral[i] = trafo(odd_y, odd_x, x_i)
else:
integral[i] = trafo(even_y, even_x, x_i)
This is common for mathematically inspried code, yet the if in there is a lot of evaluations for a condition with a very predictable pattern (True, False, True, False, ....).
Making one loop for the odd and one for the even case, respectively, usually gives some speedup.
But actually, this operation can be fully vectorized leveraging NumPy's broadcasting rules.
integral is initalised with zeros which are never used, so initializing with empty would be slightly faster.
I have already forked the repository and rewrote the code to open a PR.
Hello,
When I looked at the implementation of
_calc_kkr
I saw that there are 2 issues when it comes to speed:the code is formulated in a mathematical sense which handles the two cases of odd and even in one loop:
This is common for mathematically inspried code, yet the
if
in there is a lot of evaluations for a condition with a very predictable pattern (True
,False
,True
,False
, ....). Making one loop for the odd and one for the even case, respectively, usually gives some speedup. But actually, this operation can be fully vectorized leveraging NumPy's broadcasting rules.integral
is initalised with zeros which are never used, so initializing withempty
would be slightly faster.I have already forked the repository and rewrote the code to open a PR.
Kind regards