When using scipy.ndimage.interpolation.shift to shift a numpy data array along one axis with periodic boundary treatment (mode = 'wrap'), I get an unexpected behavior. The routine tries to force the first pixel (index 0) to be identical to the last one (index N-1) instead of the "last plus one (index N)".

Minimal example:

# module import
import numpy as np
from scipy.ndimage.interpolation import shift
import matplotlib.pyplot as plt# print scipy.__version__
# 0.18.1a = range(10)plt.figure(figsize=(16,12))for i, shift_pix in enumerate(range(10)):# shift the data via spline interpolationb = shift(a, shift=shift_pix, mode='wrap')# plotting the dataplt.subplot(5,2,i+1)plt.plot(a, marker='o', label='data')plt.plot(np.roll(a, shift_pix), marker='o', label='data, roll')plt.plot(b, marker='o',label='shifted data')if i == 0:plt.legend(loc=4,fontsize=12)plt.ylim(-1,10)ax = plt.gca()ax.text(0.10,0.80,'shift %d pix' % i, transform=ax.transAxes)

Blue line: data before the shift
Green line: expected shift behavior
Red line: actual shift output of scipy.ndimage.interpolation.shift

Is there some error in how I call the function or how I understand its behavior with mode = 'wrap'? The current results are in contrast to the mode parameter description from the related scipy tutorial page and from another StackOverflow post. Is there an off-by-one-error in the code?

Scipy version used is 0.18.1, distributed in anaconda-2.2.0

It seems that the behaviour you have observed is intentional.

The cause of the problem lies in the C function map_coordinate which translates the coordinates after shift to ones before shift:

map_coordinate(double in, npy_intp len, int mode)

The function is used as the subroutine in NI_ZoomShift that does the actual shift. Its interesting part looks like this:

Example. Lets see how the output for output = shift(np.arange(10), shift=4, mode='wrap') (from the question) is computed.

NI_ZoomShift computes edge values output[0] and output[9] in some special way, so lets take a look at computation of output[1] (a bit simplified):

# input  =         [0,1,2,3,4,5,6,7,8,9]
# output = [ ,?, , , , , , , , ]          '?' == computed position
# shift  = 4
output_index = 1in  = output_index - shift    # -3
sz  = 10 - 1                  # 9
in += sz * ((-5 / 9) + 1)
#  +=  9 * ((     0) + 1) == 9
# in == 6return input[in]  # 6 

It is clear that sz = len - 1 is responsible for the behaviour you have observed. It was changed from sz = len in a suggestively named commit dating back to 2007: Fix off-by-on errors in ndimage boundary routines. Update tests.

I don't know why such change was introduced. One of the possible explanations that come to my mind is as follows:

Function 'shift' uses splines for interpolation. A knot vector of an uniform spline on interval [0, k] is simply [0,1,2,...,k]. When we say that the spline should wrap, it is natural to require equality on values for knots 0 and k, so that many copies of the spline could be glued together, forming a periodic function:

0--1--2--3-...-k              0--1--2--3-...-k              0--1-- ...0--1--2--3-...-k              0--1--2--3-...-k      ...

Maybe shift just treats its input as a list of values for spline's knots?