-
Notifications
You must be signed in to change notification settings - Fork 413
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
Add ability to deal with masked arrays to find_intersections #372
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A little ugly, but could go in for now. Question: is only looking in one direction (i.e. you keep adding 1) enough? Do you ever need to look backwards?
metpy/calc/tools.py
Outdated
@@ -157,3 +158,35 @@ def interpolate_nans(x, y, kind='linear'): | |||
else: | |||
raise ValueError('Unknown option for kind: {0}'.format(str(kind))) | |||
return y[x_sort_args] | |||
|
|||
|
|||
@exporter.export |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that this could go away in the future, I'm not ready to export this. I'd even consider naming with a leading underscore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair - Can do. Re above - I don't think we ever need to look back. nearest_intersection_idx
shouldn't ever return a masked point.
587b78c
to
aab6a6d
Compare
Looks good to go unless you see anything else @dopplershift |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I thought of a few things. 😀
metpy/calc/tools.py
Outdated
------- | ||
Index of next non-masked element and next non-masked element | ||
""" | ||
if hasattr(a, 'mask'): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of checking here (LBYL-Look Before You Leap), use EAFP (Easier to Ask Forgiveness than Permission):
try:
...
except AttributeError:
return idx, a[idx]
hasattr()
ends up calling getattr()
anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So is that an efficiency gain or mainly style thing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ever so slight gain in efficiency has convinced me of choosing EAFP over LBYL; code clarity, of course, dominates all of that, but that's not the case here.
metpy/calc/tools.py
Outdated
""" | ||
if hasattr(a, 'mask'): | ||
next_idx = idx | ||
while ma.is_masked(a[next_idx]): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of this loop, how about:
next_idx = idx + a[idx:].mask.argmin()
Looks like we have to catch all three errors for the entire build matrix to pass. If that sounds fine, I'll fixup the commits. |
Sounds good, rebase and we should be good to go. |
eff3625
to
d1eaf20
Compare
Done! I really hope we can kill this soon - it's not pretty, but sadly necessary. |
rebasing now so it can be next in line for merge |
d1eaf20
to
387c0d3
Compare
Ready to go |
Adds a helper function and streamlines its use in
find_intersections
. It will need some tests of course, but let's start with talking about how we want to modify the inner workings.