-
Notifications
You must be signed in to change notification settings - Fork 264
TST: Validate nib-diff dtype command-line option #672
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
Conversation
Codecov Report
@@ Coverage Diff @@
## master #672 +/- ##
=======================================
Coverage 88.86% 88.86%
=======================================
Files 93 93
Lines 11434 11434
Branches 1890 1890
=======================================
Hits 10161 10161
Misses 933 933
Partials 340 340
Continue to review full report at Codecov.
|
nibabel/cmdline/diff.py
Outdated
@@ -313,7 +320,8 @@ def main(args=None, out=None): | |||
files, | |||
header_fields=opts.header_fields, | |||
data_max_abs_diff=opts.data_max_abs_diff, | |||
data_max_rel_diff=opts.data_max_rel_diff | |||
data_max_rel_diff=opts.data_max_rel_diff, | |||
dtype=opts.dtype |
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.
wouldn't work as is. In cmdline you will get a string, like "float64"
, whenever functions expect actual type, like np.float64
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.
untested code is broken code :-P
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.
Codecov appears green for it though? And I tested it in cmdline for myself. Could you please specify the use case you think I'm missing?
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 is fine because whenever we get a dtype_var
, we generally immediately turn around and run dtype(dtype_var)
, which will take np.float64
, or '<f8'
or 'float64'
.
nibabel/nibabel/dataobj_images.py
Line 340 in 7877add
dtype = np.dtype(dtype) |
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.
still would be nice to have a test which invokes main
here providing then dtype as a string.
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.
Sounds reasonable to me.
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.
Assuming these pass, please check to make sure this meets with your standards. I checked with @yarikoptic -- is this what you had in mind?
8c8e6d8
to
974a3a9
Compare
ok, let me push a tiny change just to see the proper diff for this PR -- should be only dtype specification relevant now that we merged the other into master |
oh, I am not allowed to push to @chrispycheng branch. Do you have a check mark "checked" for "Allow changes from contributors" ... see e.g https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/ |
Merging master in, it looks like this is a test/style update. |
I'm good with this if y'all are. |
Thanks @effigies ... let's just travis to complete so nothing ugly creeps in |
Seems like everything's in order |
This PR is based on PR #661
It should now be possible to modify the datatype used to compare the differences as seen below:
TODOs