Another issue-- both this and the matlab version assume that the signal is periodic (or at least continuous at the boundaries), leading to some pretty nasty gibbs phenomina (e.g. plot([x for x=0:.1:10])). Since this is pretty easy to fix by mirroring the signal (using resample([x; flipdim(x,1)],2.0)), I'm surprised that neither matlab nor this DSP code does this. If there's a speed concern, checking the difference between the first and last entry relative to the mass of the whole signal (e.g. (x1]-x[end])/norm(x)>ϵ should be a sufficient check (if their neighbors are too far from the current, simply mirroring isn't going to cut it).

I don't think that automatically mirroring the signal is a good idea, as I would want to opt into that if I wanted to actually do that.

However, I agree that allowing the multirate filters to eat some samples isn't good; if I ask for a 2//1 resampling factor, I should get exactly 2x as many samples out. For example, I would expect resample(randn(4), 2//1) to give me the number of output samples as is declared by DSP.outputlength(FIRFilter(h, 2//1), length(x)).

In my opinion, for integer rate multipliers $M$, there are two reasonable choices for the output length for an input of length $N$:

• $M*N$, as suggested here and probably the most intuitive choice
• $M*(N-1)+1$, only interpolating between given samples, not extrapolating beyond that last sample

The second choice is particularly attractive if the interpolation filter is such that it preserves the input samples (i.e. $h(0)=1, h(kM)=0$).

The current implementation seems to give an output length of $\lceil M*(N - 0.5) \rceil$, which I don't see any explanation for.

For rate multipliers $1/M$ ($M$ integer), the output length is $\lceil N/M \rceil$.

I support switching this to $\lceil N/M \rceil$ for all cases, as that appears to be the most consistent and intuitive choice. (Or maybe round-to-nearest instead of ceil, not sure.)

Would we consider such a change breaking? It does change the output in ways that may break people's code (most probably in cases where they've worked around the current quirks), so probably yes. But it's also unlikely to silently lead to wrong results, so doing this in a major version bump (or minor while pre-v1) seems fair. Or would this require some deprecation/opt-in/whatever gymnastics for one release cycle? Putting this on the milestone so that we remember to at least think about a strategy forward.