Fix output length of resample

[martinholters]

This comprises a few changes that can be considered in on their own, but later ones depend on earlier ones for proper results. In commit order:

• outputlength(::FIRRational, inputlength) is fixed to correctly predict the number of valid samples produced by filt!. (For context: filt! expects a sufficiently large output buffer and returns the number of samples actually written.)
• outputlength(::FIRArbitrary, inputlength) is improved to do this correctly more often. Unfortunately, it can still be off-by-one sometimes, which seems almost inevitable. The reason is -- somewhat simplified -- that filt! increases the time incrementally, which may be numerically different from considering the whole time-span at once. More complicated in reality, but conceptually: Starting at sample 1 and going in steps of 0.1, how many steps do you need to reach sample 2? Ten, because 10 * 0.1 == 1? No, one more, because 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 < 1. Now, to be sure to have outputlength give the correct result, I think one would have to replicate the same iterative index/phase computations, which seems excessive.
• Add rounding mode support to inputlength, specifically for RoundUp and RoundDown (where the latter is the old behavior and still the default). With RoundDown, inputlength returns the largest input length such that the actual output length will be at most the given one, i.e. outputlength(H, inputlength(H, yL)) <= yL < outputlength(H, inputlength(H, yL)+1). OTOH, with RoundUp, inputlength returns the shortest input length such that the actual output length will be at least the given one, i.e. outputlength(H, inputlength(H, yL, RoundUp)-1) < yL <= outputlength(H, inputlength(H, yL, RoundUp)).
• In resample, use inputlength in RoundUp mode to pad the input to the minimum length to get at least ceil(Int, length(x)*rate) output samples, then trim the output to the required size as necessary.

Some points I'd especially appreciate feedback on:

• Are the current tests sufficient or should I add more? If so, which?
• Are we confident with the @asserts or should that be more defensive?
• Is the RoundingMode API for inputlength appropriate? Only RoundUp and RoundDown really make sense there, I guess, so maybe not? (Or should we just drop the RoundDown behavior which might not be needed at all?)

Fixes #186.

[martinholters]

These lengths now all match expectations:

julia> 35546 / 55.55
639.8919891989199

julia> 1822 * 0.9802414928649835
1786.0

julia> 16_367_000*2 * 10_000_000/16_367_000
2.0e7

julia> 1000 * 0.012
12.0

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.90%. Comparing base (ed6c5f6) to head (27898c7).
Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #596   +/-   ##
=======================================
  Coverage   97.90%   97.90%           
=======================================
  Files          19       19           
  Lines        3248     3252    +4     
=======================================
+ Hits         3180     3184    +4     
  Misses         68       68           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[wheeheee]

After some simplification, I think there is a way to make sure that the output length matches. Is there an obstruction to generating ϕAccumulator with a pre-calculated range? Don't have time to try it out now, however.

[martinholters]

After some simplification, I think there is a way to make sure that the output length matches.

For FIRArbitrary you mean, I suppose? That would be great. I'm curious to see it!

Is there an obstruction to generating ϕAccumulator with a pre-calculated range?

Not sure what you're trying to say here. I guess we could consider changing the state from ϕAccumulator to a counter and then calculate ϕAccumulator from something like mod(counter*Δ, Nϕ). Then it would be much easier to determine the final value for that counter, I think. EDIT: But of course, in the long run, with large values of the counter, the accuracy of counter*Δ may become arbitrarily bad.

I tried to avoid putting too many changes in this PR for sake of reviewability, and rewriting the inner workings of FIRArbitrary is somewhat on the border. It's not immediately required for fixing #186, but surely closely related, so might make sense.

[wheeheee]

Yeah, that was what I meant. Didn't consider the numerical error...if only there was a better way to calculate mod(init_acc + counter*Δ, Nϕ).
About the points you raised, I actually think the current implementation makes sense, but for more documentation.
EDIT: oh, it's still WIP, never mind.

[martinholters]

One more thing I'm not 100% sure about: Currently, the target output length is ceil(length(input), ratio). Why ceil? Why not round?

[wheeheee]

One more thing I'm not 100% sure about: Currently, the target output length is ceil(length(input), ratio). Why ceil? Why not round?

I suppose you mean ceil(Int, length(input) * ratio)? The only reason I can think of is if length(input) * ratio < 0.5, this still gives an output, and somebody wants that.

[martinholters]

I suppose you mean ceil(Int, length(input) * ratio)?

Of course, yes.

The only reason I can think of is if length(input) * ratio < 0.5, this still gives an output, and somebody wants that.

Hm... That's not a reason that convinces me. A single sample does not seem that much more helpful than none. Would round be more intuitive? (It is to me.) Change?

[wheeheee]

Perhaps we should take reference to what scipy or Matlab does?

[martinholters]

Good point. Looks like they both round up (for Matlab I found that to be documented as well), so reasonable for us to do the same.

I guess then this is good to go then.

[wheeheee]

Merge?

[wheeheee]

Hm, but actually the assertion is not always true...

julia> resample(ones(100), 2.00)
ERROR: AssertionError: length(y) >= outLen

[martinholters]

Ah yes, turns out inputlength was incorrect for cases where no rounding in the length computation occurred. Fix incoming.

Should we reconsider this question: Are we confident with the @asserts or should that be more defensive?

[wheeheee]

Hm, I think the asserts should be correct. Not sure what you mean by more defensive, do you propose to remove them?

[martinholters]

Not sure what you mean by more defensive, do you propose to remove them?

That particular one, yes. It arguably would have been better to get a result that is one sample shorter than expected than to see an assertion error. However, that might also have meant that this error in inputlength might have hidden for much longer. So I tend to leaving these @asserts in and dealing with bugs thus uncovered as they come in.

[wheeheee]

I agree with that approach. Though users may still want the output that's already calculated...maybe there is a good way to do this kind of exception handling I'm unaware of? Or return length(y) >= outLen etc. together, which is also unwieldy...

[martinholters]

Then let's leave the @asserts in. We can always reconsider if these actually do fire in practice.

Do you want to take this for another test flight and see if you find more problems or should we merge?

[wheeheee]

Ran it with random inputs, was ok. LGTM, go ahead.