You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I opened raphaelvallat/yasa#50 (comment) and the same improvement could be done here, too. The idea is to avoid for loop, which takes more time than numpy ufuncs, especially when the number of events is huge.
My proposal for _index_to_events is the following:
Two potential problems here: first, there might be a reason to avoid scipy here; second, this is not fully compatible with the current implementation, as it would merge events that overlap in time. Are they really problems or not in the scope of the usage of this function?
Please tell me how you think about it. Is it really beneficial to do so, etc :)
The text was updated successfully, but these errors were encountered:
I opened raphaelvallat/yasa#50 (comment) and the same improvement could be done here, too. The idea is to avoid for loop, which takes more time than numpy ufuncs, especially when the number of events is huge.
My proposal for
_index_to_events
is the following:This is fully compatible with the current implementation according to my tests. For benchmarks, see raphaelvallat/yasa#50 (comment).
For
_events_to_index
I tend to usescipy
,Two potential problems here: first, there might be a reason to avoid
scipy
here; second, this is not fully compatible with the current implementation, as it would merge events that overlap in time. Are they really problems or not in the scope of the usage of this function?Please tell me how you think about it. Is it really beneficial to do so, etc :)
The text was updated successfully, but these errors were encountered: