Skip to content

Conversation

@jokasimr
Copy link
Contributor

Adding a peak finding utility for scipp/essdiffraction#179

@jokasimr jokasimr requested a review from jl-wynen June 25, 2025 13:06
Copy link
Member

@jl-wynen jl-wynen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a bunch of comments. But please start with this:

Many arguments in kwargs should be dimensionfull, e.g., height and width, and those units have to match the units of da or be converted to those. So the arguments should be handled explicitly instead of simply being forwarded.

Additionally, this function does not forward the second return value from scipy. This means that several arguments don't function properly (they would normally trigger extra return values).

A routine that locates "peaks" in a 1D signal.
This is a wrapper around :py:funct:`scipy.signal.find_peaks. See there for a
complete description of parameters.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add Parameters and Returns sections? Otherwise, they are not shown properly in sphinx.
Also, please describe the return value. I.e., what do the values represent and what coords exist.


from scipy.signal import find_peaks

if da.ndim != 1 or not isinstance(da, DataArray | Variable) or da.bins is not None: # type: ignore[redundant-expr]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need the isinstance check. We don't do that elsewhere and the type hint should be enough.

@jokasimr jokasimr requested a review from jl-wynen July 14, 2025 08:32
@jokasimr jokasimr enabled auto-merge (squash) August 26, 2025 08:17
@jokasimr jokasimr disabled auto-merge August 26, 2025 12:35
@jokasimr
Copy link
Contributor Author

jokasimr commented Aug 26, 2025

I changed my mind.
I think it is better to return the peak indices like the scipy api does, instead of the peak values like we did here before.

It's easy for the users to obtain the peak values from the indices anyway, but it's more difficult to go the other direction.

@jokasimr jokasimr merged commit e877537 into main Aug 26, 2025
4 checks passed
@jokasimr jokasimr deleted the peak-finding branch August 26, 2025 13:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants