include interpolation weights in DFT slice output

[stevengj]

This ensures that empty dimensions are collapsed correctly. I think this should fix #784 — what was happening is that at "unlucky" resolutions where the DFT slice fell between two pixels, the collapse_empty_dims was summing over two pixels in the empty direction, but without the interpolation weights this effectively doubled the field value, resulting in the factor-of-two oscillation observed in #784.

One downside of this PR is that, at the edges of the output volume, the edge pixels might be multiplied by an integration weight factor (between 0 and 1). It might be nice to only include the interpolation weights for empty dimensions, but not for edge pixels, but that would require some additional work (e.g. a different IVEC_LOOP_WEIGHT function or a modified loop_in_chunks). Update: Now the PR only includes the empty-dimension interpolation weights, and not the edge integration weights.

[oskooi]

Running this on the test in #784 for a resolution of 40 (which was producing incorrect results), the "interior" points returned by get_dft_array are now correct. It would be nice to also correct the endpoints.

[oskooi]

For some reason, the latest commit seems to not have fixed the endpoints and the interior points are just as they were in #784 (i.e. off by an overall scale factor).

[stevengj]

@oskooi, should be fixed now.

[oskooi]

Indeed everything is working correctly now (i.e. get_dft_array is no longer resolution-dependent and the endpoints are fixed). The norm of the relative difference in the two fields is decreasing (mostly monotonically). Shown below are results for resolutions of 40, 50, 60, and 70 with norms of 3.31022, 2.47782, 1.49521, and 1.63235.