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

peak fitting functions ought to return peak parameters as tuples for easier unpacking #21

Open
dylanhross opened this issue Nov 22, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@dylanhross
Copy link
Collaborator

I want to be able to do something like

peaks = find_peaks_1d_gauss(x_data, y_data, *other_params)
for peak_x, peak_ht, peak_wt in peaks:
    # iterate one peak at a time
    # and do stuff with the peak parameters
    ...

but instead it just returns separate arrays for each of the fitted parameters (x, ht, wt) so that you have to use zip to iterate peak by peak. I feel that iterating peak by peak (without zip, as in the example above) is a much more rational use case so these functions should return a list split by peaks rather than lists split by peak parameters.

Also a possible improvement would be to make them into generators that yield one peak at a time.

@dylanhross dylanhross added the enhancement New feature or request label Nov 22, 2023
@dylanhross
Copy link
Collaborator Author

Something else to think about: I already have an amount of code that uses these functions as they currently exist. Making this change outright would break those applications. Maybe an incremental change would work better. For instance, add an optional kwarg like pack (default to False) which would make the functions return the packed tuples row-wise instead of column-wise as they currently are. This is like the inverse of the unpack option in numpy.genfromtxt. This change would make the new behavior opt-in at the beginning, then in later releases the default value could be changed to True making the old behavior opt-in instead, and finally maybe even completely deprecate the old behavior later on down the line.

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

1 participant