# Consistent use of FilterCoefficients in DSP.jl?

**URL:** <https://discourse.julialang.org/t/consistent-use-of-filtercoefficients-in-dsp-jl/71119>\
**Category:** Signal and Image Processing\
**Tags:** dsp\
**Created:** [November 8, 2021, 1:22am UTC](https://discourse.julialang.org/t/consistent-use-of-filtercoefficients-in-dsp-jl/71119 "2021-11-08T01:22:53Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![mbaz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbaz/32/17295_2.png) [@mbaz](https://discourse.julialang.org/u/mbaz)\
**Post date:** [November 8, 2021, 1:22am UTC](https://discourse.julialang.org/t/consistent-use-of-filtercoefficients-in-dsp-jl/71119/1 "2021-11-08T01:22:53Z")

</div>

In DSP.jl, some filter design commands return a filter object, while others (like `remez`) return a plain Float64 vector. This is inconvenient because many of the package functions don’t take vectors as arguments.

I have browsed the issues list, but I couldn’t figure out what the rationale is for this decision. What would be the difficulty of having `remez` and `FIRWindow` return a filter object instead of a plain vector?

One can manually convert a vector of coefficients to a `PolynomialRatio`, but why force the user to do this, instead of returning a `PolynomialRatio` in the first place?