Breaking Changes

[hamzaelsaawy]

I am wondering how much appetite there is for breaking API changes and a new version, since there are a couple I am thinking of implementing:

• [x] dropping 0.6 support (reduce load of carrying around Compat, and align with v1+)
• [x] drop all deprecated syntax (eg ZPKFilter, TFFilter)
• [x] add domain (discrete/analog) information to filter coefficients (#170, #135, #118)
• [ ] reduce reliance on parameterized calls (ZeroPoleGain{Z,P,K}) with nicer syntax unless user explicitly requires control over types
• [ ] similar to #142, add warnings when converting a ZeroPoleGain to PolynomialRatio{Float64} object with non-zero imaginary parts to its coefficients (currently, the conversion dumps the imaginary parts)
• [ ] change ZeroPoleGain{Tr, K}, so that all roots share one type, similar to PolynomialRatio

I realize this is a lot of changes, and some are probably not welcome, but I'm open to suggestions.
If not, I will stick to PRs that don't change the API.

[ssfrr]

I don't have a lot of time to spend on DSP maintenance these days so take my opinion with a grain of salt, but I do think there are some crufty bits of DSP.jl that have built up over time that can be cleaned up. I'm thinking of things like merging conv and conv2 (#202), and it also seems like there's some strange separation between conv and filt with an FIR filter, which should be the same thing. I haven't had time to do a thorough consistency review, but I think that would be a good contribution.

• I'm fine with dropping 0.6 support with the next release
• I think that things that have been deprecated should be dropped in the next version bump. It might even be time to put together a 1.0 milestone with a checklist for things we want to fix/change.
• agreed silently dropping imaginary components seems bad, should that be a InexactError just like Float64(1+2im)?

In general I'm definitely fine with turning bad behavior into errors. The only thing to be careful of is when results get silently changed.

[hamzaelsaawy]

I definitely vote for an official milestone checklist since I am fairly new here and wouldnt want to change things people are fine with.

And I think an InexactError or an ArgumentError like #257 both make sense. To complicate things though:

r(z) = imag(z) / eps(real(z))

N = 30
ripple = 5
f = Chebyshev1(N, ripple)
pp = Polynomials.poly(f.p)

maximum(abs.(r.(pp.a)))
# 5.625

So even converting filters from the design module returns imaginary parts that are above machine epsilon (for large filter taps and obscene ripples like 5db)

[martinholters]

I'm very much in favor of trying to get the wrinkles straightened out, even if that means making breaking changes. I've created a 1.0 milestone and added the first issues. Feel free to add more (or add comments to issues requesting them to be added if you lack permissions).