Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cycles.detect_cycles() performance improvement #71

Open
alcantarar opened this issue Sep 27, 2021 · 1 comment
Open

cycles.detect_cycles() performance improvement #71

alcantarar opened this issue Sep 27, 2021 · 1 comment
Labels
enhancement New feature or request

Comments

@alcantarar
Copy link
Contributor

I noticed that cycles.detect_cycles() loops through each frame of ts.data to determine which frames exceed the defined threshold. Avoiding loops would improve efficiency, especially if users have timeseries data with a high sampling frequency or duration.

Describe the solution you'd like
Avoid loops if possible.

Describe alternatives you've considered
Here's the shameless plug for how I've approached gait cycle identification in the past... See splitsteps() in https://github.com/alcantarar/dryft/blob/master/dryft/signal.py. The core component is that you compare the entire array to the threshold, then use np.diff() to identify when the signal is crossing the threshold with a positive (events == 1) or negative (events == -1) slope.

compare = (vGRF.flatten() > threshold).astype(int)
events = np.diff(compare)
stance_begin_all = np.squeeze(np.asarray(np.nonzero(events == 1)).transpose())
stance_end_all = np.squeeze(np.asarray(np.nonzero(events == -1)).transpose())

Maybe this approach is helpful, maybe it's not. I designed it for running GRF data, with some built-in checks for cycles that were suspiciously too long/short.

Additional context
N/A

Are you able and willing to help?
here is a test script that shows splitsteps() in action with real world GRF data.

@alcantarar alcantarar added the enhancement New feature or request label Sep 27, 2021
@felixchenier
Copy link
Collaborator

Thanks a lot @alcantarar

In fact cycles.detect_cycles() will be refactored someday (issue #35). It currently attempts to do too much: finding cycles using different threshold criteria, while at the same time ignoring glitches or bad cycles using other criteria, all this while mixing up fundamentally different concepts like rejection of a glitch vs a proper cycle that doesn't meet minimal requirements. It mostly works for now, but it should be better. I'm still not sure what is the most API for it yet.

I will be sure to check your code, thanks for your plug! I'm curious how your method would work on wheelchair propulsion, which is what I mainly do, since phase transitions based on pushrim reaction forces are much less clear cut than in gait. To be continued...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants