-
Notifications
You must be signed in to change notification settings - Fork 27
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
Make UVFlag.__add__ iterate over _data_params #844
Conversation
Commit names look silly because I didn't understand how pre-commit works. Also wondering if we should tackle #653 while we're at it. |
The issue you mentioned is hefty but if you feel up to it I would be glad to finally close it. |
Well, the branch name is appropriate, but I realize I'd like this change merged in ~soon. Maybe we can do a quick merge when CI passes and work on the next part afterward? |
Codecov Report
@@ Coverage Diff @@
## master #844 +/- ##
==========================================
+ Coverage 99.03% 99.12% +0.09%
==========================================
Files 28 29 +1
Lines 9854 10896 +1042
==========================================
+ Hits 9759 10801 +1042
Misses 95 95
Continue to review full report at Codecov.
|
Just want to pop in here. This will require a rebase now after the windows PR got merged in. |
a0b7412
to
d7935b9
Compare
Rebase complete |
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.
Thanks for the work on this @mwilensky768. It makes it much simpler.
I do have one comment about the comment you left concerning the iteration loop and want to discuss how to best handle the cases where optional parameters don't match.
I also have a request that is not strictly related to your PR but during my look at the file i noticed this line should read this.mode
, if you wouldn't mind changing it I would appreciate it.
pyuvdata/pyuvdata/uvflag/uvflag.py
Line 1475 in d7935b9
"added to object of mode " + this.type + "." |
pyuvdata/uvflag/uvflag.py
Outdated
# Will fail with AttributeError if the objects have different _data_params | ||
# Might want a more straight-forward check ahead of time |
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.
This comment makes me a little nervous. I would prefer if the check was added as a part of this PR. We already know they must be the same mode
and type
which, as long as the user hasn't altered the object's state, forces the required parameters to be the same. So this may not actually be an issue for required parameters.
The other question is what to do if the optional parameters exist on one and not the other?
Erroring seems extreme since it is an optional parameter. We could throw a warning, and then fill in the missing data with zeros? That seems a little weird though too but not sure what the best solution is.
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.
I think filling in a weights_square_array
with zeros will cause problems down the line in the application I have in mind. I guess if this attribute was vestigial after a mode
conversion (metric to flag), and you were adding flag objects, maybe you would not want an error. Could be a warning in one case and an error in the other? Of course, as additional optional parameters are developed, we may have to rethink this line of reasoning.
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.
Yeah it definitely gets complicated 🤔 I'm okay with the warning/error differential depending on cases. But we'll still need to eloquently handle when parameters exist on one object and not the other. Maybe it just makes them incompatible in the case where they are not vestigial?
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.
I think that's a good start. I don't know what the best check is. Not sure how you feel about try/except. One way would be
for attr in this._data_params:
try:
setattr(this, attr, np.concatenate(...))
except AttributeError:
vestigial = some_check_for_vestigial (mode=='flag' for now?)
if vestigial:
warning
setattr(this,attr, np.concatenate(...)) (different ... here)
else:
raise ValueError("UVFlag objects are not compatible for addition")
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.
I think that could be a good start. I'm not a huge fan of the try/except (despite it being the pythonic way). But could just have an if not hasattr()
instead.
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.
Error message could of course be more verbose
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.
Oh, yeah if not hasattr
is definitely simpler/fewer lines/easier to test. I'll get to work.
I've now added an attribute check that complains if |
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.
I definitely think I like this version better. If @adampbeardsley could weigh in I would appreciate him taking a look too.
Sorry it took so long for me to look at this. Overall it looks good, thanks for putting in the effort Mike!
back into |
@adampbeardsley I believe my newest commits accomplish everyone's goals. |
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.
Thanks @mwilensky768 !
This PR ensures that all data-like parameters are concatenated appropriately during addition of two UVFlag objects.
Description
The data-like attributes to be concatenated were hardcoded in
__add__
. Now an iteration overUVFlag._data_params
catches all of them, including the optionalweights_square_array
, if present.Motivation and Context
This enhancement ensures concatenation of the optional parameter
weights_square_array
if it exists, and is also a little friendlier to people subclassing UVFlag. See issue #843Types of changes
Checklist:
Bug fix checklist:
New feature checklist:
Breaking change checklist:
Documentation change checklist:
Version change checklist:
Build or continuous integration change checklist: