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

Feature calculators touchups #1103

Merged

Conversation

Scott-Simmons
Copy link
Contributor

@Scott-Simmons Scott-Simmons commented Jan 9, 2025

Various touchups to the feature calculators.

The changes here are intended to improve code clarity by refactoring a few variables with more meaningful names and simplifying complex expressions.

Easiest to go commit by commit.

@Scott-Simmons Scott-Simmons force-pushed the feature-calculators-touchups branch 2 times, most recently from d4d1862 to 5870185 Compare January 9, 2025 10:50
@Scott-Simmons Scott-Simmons marked this pull request as ready for review January 9, 2025 10:51
Copy link
Collaborator

@nils-braun nils-braun left a comment

Choose a reason for hiding this comment

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

Thanks again for your work! I am ok with most changes, especially the format to f-strings is a change that really helps readability. There are just a few comments I had.

else:
return np.nan
avg = np.mean(x)
if avg != 0:
Copy link
Collaborator

Choose a reason for hiding this comment

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

As you are already touching it...
It would probably be nicer to have the edge case as the if branch, so just switching the order.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@@ -1099,23 +1098,21 @@ def fft_coefficient(x, param):
def complex_agg(x, agg):
if agg == "real":
return x.real
elif agg == "imag":
if agg == "imag":
Copy link
Collaborator

Choose a reason for hiding this comment

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

I know that writing an else after a return does not make sense, but honestly I think it makes it clearer what is meant. If you have strong feelings about it, keep the if, but if not, maybe revert it :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

return np.angle(x, deg=True)
return None
Copy link
Collaborator

Choose a reason for hiding this comment

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

Good point. Maybe instead of returning None one should raise an exception because this should not happen?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

skew=get_skew,
kurtosis=get_kurtosis,
)
return (
Copy link
Collaborator

Choose a reason for hiding this comment

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

As you are touching it anyways ;)
Can you extract a variable for the y centroid? It only needs to be calculated once

Copy link
Contributor Author

Choose a reason for hiding this comment

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



@set_property("fctype", "simple")
def range_count(x, min, max):
def range_count(x, min_val, max_val):
Copy link
Collaborator

Choose a reason for hiding this comment

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

I see your intention: min and max are python keywords, so they should not be used. But the config of the feature extractors is part of our API and changing it is in principle a breaking change, which we should be careful about.
How about keeping the function parameters the same but renaming it internally so that we do nit have any potential of mixup?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

API and changing it is in principle a breaking change,

Yep absolutely see your point - I dont think worth making a breaking change over this - will amend

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Reverted 1e42930

Changing variable names because this overloads the builtin python functions `max` and `min`.

Best to rename these to reduce any risk
Use list(dict.items())
Reverts changes to the argument names for range count, see blue-yonder@3e3f936#r1915531370
- Extract out centroid as a var
- Raise exception and add Literal type sig
- Switch order of branch evaluation
@Scott-Simmons Scott-Simmons force-pushed the feature-calculators-touchups branch from 987d677 to 5b26355 Compare January 19, 2025 06:14
@Scott-Simmons
Copy link
Contributor Author

Scott-Simmons commented Jan 19, 2025

Thanks again for your work! I am ok with most changes, especially the format to f-strings is a change that really helps readability. There are just a few comments I had.

No worries! Some remaining f-strings were added in this extra commit: 4bf916d

Copy link
Collaborator

@nils-braun nils-braun left a comment

Choose a reason for hiding this comment

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

Looks very good to me now!

@nils-braun nils-braun merged commit fdfeaae into blue-yonder:main Jan 25, 2025
5 checks passed
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.

2 participants