Suppress warnings regarding one-dimensional arrays changes in scipy 0.18

[arokem]

undoes changes introduced in: b6fc887

Should resolve #1107

[coveralls]

Coverage remained the same at 88.455% when pulling c903834 on arokem:affine-sp-18 into acee6d7 on nipy:master.

[codecov-io]

Codecov Report

Merging #1204 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master    #1204   +/-   ##
=======================================
  Coverage   85.96%   85.96%           
=======================================
  Files         221      221           
  Lines       27073    27073           
  Branches     2770     2770           
=======================================
  Hits        23273    23273           
  Misses       3123     3123           
  Partials      677      677

Impacted Files	Coverage Δ
dipy/align/reslice.py	97.05% <100%> (ø)	⬆️

---

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 acee6d7...c903834. Read the comment docs.

[MarcCote]

This looks good. I can merge it later today.

[dimrozakis]

Hey @arokem & @MarcCote

I don't think that merging this MR was the right way to go. It effectively reverts b6fc887 which had reduced completion time by about a half.

I also explained this in #1107 (comment)

I'm not sure I understand what the problem was. Scipy's docs clearly state that it is valid to supply a 1D array as the matrix argument:

A diagonal matrix can be specified by supplying a one-dimensional array-like to the matrix parameter, in which case a more efficient algorithm is applied.

It seems wrong to me to revert the use of a well documented and supported feature of affine_transform and double completion time, just to get rid of a warning. Isn't it possible to just actually suppress it (as the title of this MR suggests) instead?

[arokem]

OK - good point. The problem with that warning was that it suggested that we are doing something wrong. I still don't understand whether we are, but I think that you are saying that it's all fine. What are your thoughts about this comment that followed? https://github.com/n ipy/dipy/issues/1107#issuecomment-256237171

…

On Thu, Mar 30, 2017 at 10:35 AM, Dimitris Rozakis ***@***.*** > wrote: Hey @arokem <https://github.com/arokem> & @MarcCote <https://github.com/MarcCote> I don't think that merging this MR was the right way to go. It effectively reverts b6fc887 <b6fc887> which had reduced completion time by about a half. I also explained this in #1107 (comment) <#1107 (comment)> I'm not sure I understand what the problem was. Scipy's docs <https://docs.scipy.org/doc/scipy-0.19.0/reference/generated/scipy.ndimage.affine_transform.html> clearly state that it is valid to supply a 1D array as the matrix argument: A diagonal matrix can be specified by supplying a one-dimensional array-like to the matrix parameter, in which case a more efficient algorithm is applied. It seems wrong to me to revert the use of a well documented and supported feature of affine_transform and double completion time, just to get rid of a warning. Isn't it possible to just actually *suppress* it (as the title of this MR suggests) instead? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1204 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHPNrn3nSe3pkASFSiRbkBlD7nsl6wWks5rq-ftgaJpZM4MtMPc> .

[dimrozakis]

Hey @arokem. Thanks for the quick response!

Both versions of calculation mentioned in scipy's docs, np.dot(matrix,o) + offset and matrix * (o + offset) yield the same result for a diagonal matrix when offset is 0. I agree with @jchoude in that:

Currently, our behavior is consistent, since the offset that we pass is always np.zeros(3,). We might simply need to ensure that we don't change the offset, else the result might not be consistent between versions of scipy.

So perhaps this PR should be reverted, and replaced with a comment on the relevant code warning anyone from messing with offset in the future?

[dimrozakis]

The problem with that warning was that it suggested that we are doing something wrong. I still don't understand whether we are, but I think that you are saying that it's all fine.

I think the warning was put there by scipy's devs to notify users of a change in the behavior of a parameter we don't use. As far as I can tell, we're not doing anything wrong here.

[arokem]

How's this? #1206

…

On Thu, Mar 30, 2017 at 2:56 PM, Dimitris Rozakis ***@***.***> wrote: The problem with that warning was that it suggested that we are doing something wrong. I still don't understand whether we are, but I think that you are saying that it's all fine. I think the warning was put there by scipy's devs to notify users of a change in the behavior of a parameter we don't use. As far as I can tell, we're not doing anything wrong here. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1204 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHPNhGzbLxv55Z5ZPHw-vwORhf31NvOks5rrCUYgaJpZM4MtMPc> .

[dimrozakis]

That seems great. Thanks a lot! On Mar 31, 2017 1:08 AM, "Ariel Rokem" <notifications@github.com> wrote: How's this? #1206

On Thu, Mar 30, 2017 at 2:56 PM, Dimitris Rozakis ***@***.***> wrote: The problem with that warning was that it suggested that we are doing something wrong. I still don't understand whether we are, but I think that you are saying that it's all fine. I think the warning was put there by scipy's devs to notify users of a change in the behavior of a parameter we don't use. As far as I can tell, we're not doing anything wrong here. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1204 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHPNhGzbLxv55Z5ZPHw-

vwORhf31NvOks5rrCUYgaJpZM4MtMPc>

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1204 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFLUDd9BHZxcPGff4bhbCdi0npse-QIOks5rrCfZgaJpZM4MtMPc> .