Skip to content

MRG: fix bug in get_fdata return value #638

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

Merged
merged 4 commits into from
Jun 11, 2018

Conversation

matthew-brett
Copy link
Member

We document that get_fdata returns the contained array, from an array image, if
it is of the desired type, but in fact we were always making a copy.

This revealed from updating the doctests in the documentation.

Refactor the image API tests to be a bit more readable (a tiny bit), fix the
bug, and add tests.

There was too much indentation, making the code harder to follow. Break
the code up into helper methods.  Remembering (after forgetting) that
method names beginning with `validate` will get called automatically by
the validator post-processing.
Make dtypes explicit for return, in order to allow sub-classes to
override the storable dtypes.
The `get_fdata` method should return the contained array if the array is
the correct (matching) floating point type.  This was not happening
because of I used the `astype` method, which, by default, does a copy.
Fix and test.
@coveralls
Copy link

coveralls commented Jun 7, 2018

Coverage Status

Coverage decreased (-0.009%) to 91.789% when pulling 58c8d1a on matthew-brett:array-image-casting into dfd113c on nipy:master.

@effigies
Copy link
Member

effigies commented Jun 7, 2018

Looks like Windows+3.4 in particular doesn't like this. From a quick glance, it's unclear why these issues are raising here and not in other cases.

@effigies
Copy link
Member

effigies commented Jun 7, 2018

Also, as a point of information, you've previously said that get_fdata() should always do a copy: #492 (comment)

@matthew-brett
Copy link
Member Author

Yeah - that Appveyor error is very odd. Here's what I believe to be the same code, passing: https://ci.appveyor.com/project/matthew-brett/nibabel/build/1.0.17 . I couldn't replicate the test error on the Appveyor machines, attached via remote desktop.

For the always copy comment, what I think I meant was, it always copies if it's loaded from disk. The previous tests seemed to imply that I had planned to return the internal array object only if it was already the given datatype - it's just that they weren't testing that, because they were not testing creating array images with float64 data. If you think that's the wrong thing to do, we can revisit.

The returned array won't behave like a copy in all circumstances, because of the caching. So, although always returning a copy might be more consistent, it does soak up a lot of extra memory, and the API is already not consistent with respect to copies, because of the caching.

@effigies
Copy link
Member

effigies commented Jun 7, 2018

Oh, gotcha. That makes sense.

I'm rerunning the AppVeyor build to see if it does replicate. Maybe it was just a weird cache.

@effigies
Copy link
Member

effigies commented Jun 7, 2018

It passed. Who knows what was up with that. I'm 👍 to merge.

@effigies
Copy link
Member

effigies commented Jun 7, 2018

@yarikoptic I assume get_fdata isn't going to affect the tests you're currently running... Any objections to merging this and the doc fixes into rel/2.3.0?

@codecov-io
Copy link

codecov-io commented Jun 7, 2018

Codecov Report

Merging #638 into master will decrease coverage by 0.01%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #638      +/-   ##
==========================================
- Coverage   88.83%   88.81%   -0.02%     
==========================================
  Files          92       92              
  Lines       11278    11278              
  Branches     1848     1848              
==========================================
- Hits        10019    10017       -2     
- Misses        925      926       +1     
- Partials      334      335       +1
Impacted Files Coverage Δ
nibabel/dataobj_images.py 95.55% <100%> (-4.45%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update dfd113c...58c8d1a. Read the comment docs.

matthew-brett added a commit to matthew-brett/nibabel that referenced this pull request Jun 8, 2018
Float64 array images return the array from get_fdata, with default input
arguements, but other data types return the array cast to float64.

Tests will fail before merge of fix in
nipy#638 .
@effigies
Copy link
Member

@matthew-brett This LGTM. Did you want to get this and #637 in before the 2.3.0 release?

@matthew-brett
Copy link
Member Author

Yes, please - I would love to get these in before the release.

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.

4 participants