This does make a lot of sense to me, but on first glance, I am surprisingly unsure if that generalization is maybe surprising after all.
I think the right question is whether there are use-cases where not using a value at all would be wrong (i.e. normally you use all values at least once). I can't think of any, but I am not sure; clearly your use-case not using the values, that is what you want.

Not sure why it should matter whether the window size is exactly 1 smaller at most conceptually. Why not use max(0, ...) for the new dimension?

A helpful thing would be to see what the prior art is in pandas/scipy? E.g. pandas rolling window operations and scipy.ndimage filters?

A helpful thing would be to see what the prior art is in pandas/scipy? E.g. pandas rolling window operations and scipy.ndimage filters?

The Python standard library has itertools.pairwise, for windows of length 2. For an input of length 1 its output has length 0:

>>> import itertools
>>> list(itertools.pairwise([0, 1, 2]))
[(0, 1), (1, 2)]
>>> list(itertools.pairwise([0, 1]))
[(0, 1)]
>>> list(itertools.pairwise([0]))
[]

pandas.Series.rolling does a different kind of operation from sliding_window_view: its output is as long as its input, padded with NaNs as necessary.

Not sure why it should matter whether the window size is exactly 1 smaller at most conceptually. Why not use max(0, ...) for the new dimension?

If (length of window) > (length of array) + 1 both raising an exception, the current behaviour, and your suggestion, which agrees with itertools.pairwise, are reasonable. However, changing from the former to the latter is a change of functionality, whereas my pull request for the case that (length of window) = (length of array) + 1 resolves a bug and so should be less controversial.

Whether

(length of result) = (length of array) - (length of window) + 1

or

(length of result) = max((length of array) - length of window) + 1, 0),

if

(length of window) = (length of array) + 1

then

(length of result) = 0.

resolves a bug and so should be less controversial

I don't understand the difference in why one should be a bug and the other not, to me they seem the same: In either case there is valid "boundary" data that is not part of the result.
The pairwise is indeed prior art, it seems ndimage is not (like rolling it always returns the same length as the input, and has a parameter which might mask boundary values min_periods).

I don't understand the difference in why one should be a bug and the other not, to me they seem the same: In either case there is valid "boundary" data that is not part of the result.

Both

1. The behaviour that (length of result) = (length of array) - (length of window) + 1; and
2. The behaviour that (length of result) = max((length of array) - length of window) + 1, 0)

are reasonable.

However, the current behaviour, that (length of result) = (length of array) - (length of window) + 1 unless (length of result) would equal 0 is not reasonable. There ought not to be such an arbitrary exception.

What doth hinder this to be merged?

@seberg, the following table shows how the length of the result in a dimension depends on the lengths of the array and the window in that dimension, under the three behaviours discussed.

Both behaviours for window > array + 1 are reasonable; this request does not change the behaviour in that case; it simply corrects the mistake in the case that window = array + 1.

I desire a review of this request.

Sorry, most of our reviewer bandwidth is going toward fixing urgent problems required for 2.0.0rc1.

FWIW, I still strongly disagree that the window-size calculation matters. In my view the only thing that matters is that there are data points which are not part of the result.

list(itertools.pairwise([])) is indeed some prior art which just discards the result (and also works for fully empty, btw.).
Maybe short of more prior art, you can explain the use-case as a motivation?

I am not sure if there is much surprise with an empty result, so I am OK with it, but I wouldn't like to hear one more opinion clearly in favor. Unlike many other "empty array" results which I would find obvious, I still think this one has a slightly different quality.

numpy.diff behaves like itertools.pairwise:

>>> import numpy as np
>>> np.diff(np.arange(4))
array([1, 1, 1])
>>> np.diff(np.arange(3))
array([1, 1])
>>> np.diff(np.arange(2))
array([1])
>>> np.diff(np.arange(1))
array([], dtype=int64)
>>> np.diff(np.arange(0))
array([], dtype=int64)

It is surprising that numpy.diff is not equivalent to

def diff(a, axis=-1):
    pairs = np.lib.stride_tricks.sliding_window_view(a, 2, axis=axis)
    return pairs[..., 1] - pairs[..., 0]

at least whenever a.shape[axis] >= 1.

Between n values there are n-1 pairs. It is a bug for sliding_window_view to have an ad hoc exception for n=1.

Good point! np.diff pushes me slightly in favor. I am still adament about dropping the idea that this was ever an "ad hoc exception for n=1". I don't see it that way, n=0 is no different (also not in diff as you said). There are two choices:

1. You raise an error (what we have)
2. You always return an empty result.

the current choice of returning an empty result for "n=1" but not "n=0", at least to me doesn't make sense. What does make sense is to call it an enhancement to allow empty results in general.

@seberg, no. Consider the case where the window is of length 2.

As you can see, returning a result of length 0 when the array is of length 1 follows the pattern for arrays of length 2 or more. There is no reason whatever to raise an exception. Why should n=1 be treated differently from n=2, n=3 and so on?

the current choice of returning an empty result for "n=1" but not "n=0", at least to me doesn't make sense.

The proposal simply treats n=1 the same as n=2, n=3, n=4 and so on.

@seberg,

n=0 is no different

Returning an empty array for n=0 is different, because then it is no longer true that (result length) = (array length) - (window length) + 1.

@JDawson-Camlin let's just agree to disagree. I simply don't think the formula result_length = array_length - window_length + 1 is conceptually important to what the result should be for these.