Grant Griffin <nobody@example.com> wrote in
news:5fbdd$4b87cb38$407e2ca9$5534@EVERESTKC.NET:
> steveu wrote:
>>> I'm finally about ready to release an IIR filter design program called
>>> - you guessed it - ScopeIIR (TM).
>>>
>>> It currently supports the basic design types of Butterworth,
>>> Chebyshev, and Elliptic. I'm trying to finalize the default and
>>> maximum IIR filter order that the program will support. To help me do
>>> that, please tell me about your experiences with IIR filter order,
>>> assuming the above types and implementation via biquads, where
>>> applicable:
>>>
>>> - Minimum order: (I assume 1)
>>> - The typical order you use for most problems
>>> - The maximum order you've ever used in a real system
>>> - The maximum order that you consider feasible to design using 8-byte
>>> IEEE floating point ("double")
>>> - The maximum order that you consider feasible to implement in various
>>> numeric formats. I'm particularly interested in 8-byte and 4-byte
>>> IEEE, and any fixed-point formats you've used (please specify).
>>
>> That seems a slightly odd set of questions. The main driver for word
>> length is not the order of the IIR filter, but just how low in the band
>> the poles and zeros sit.
>>
>> Steve
>>
>
> Thanks for your input, Steve, but I guess I'm looking for something a
> little more concrete. Please note that all of these questions ask for
> experiences and opinions rather that an exact mathematical answer. For
> example, the question of what is the maximum order that you've ever used
> is answerable: what _is_ the maximum order that you've ever used? (I
> never thought comp.dsp would be short of unsubstantiated experiences and
> opinions. ;-)
>
> Think of this from the user's and programmer's point of view. The user
> would like to be successful almost all of the time when working within
> the specified limitations. So, the programmer would like to define some
> sort of simple limitations which the user will be successful within. In
> that vein, ScopeFIR's Parks-McClellan design is explicitly limited to
> 16384 taps even though there is no intrinsic limitation on that
> internally - it's just that PM designs often fail with a larger number
> of taps.
>
> Of course, the possibility exists that the user could torture-test
> ScopeIIR with an extreme design (either accidentally or on purpose) and
> then the design and/or implementation process would fail even within the
> specified limits on IIR filter order.
>
> So, I guess I'm looking for parameters that cover the common experience.
> For example, the question of what order you have typically used is
> needed to fill in a default value of order - which the user can change,
> of course. So what might such a default value be? I'm currently using
> 4.
>
> thanks,
>
> Grant
I think you should have provisions for quantization of at least the
following:
floating point:
32 bit IEEE
40 bit IEEE (SHARC)
64 bit IEEE
fixed point:
arbitrary length to 64 bits
It is not hard to write DF1 in fixed point with double precision. Here is
an ADI ap note:
http://www.analog.com/static/imported-files/application_notes/EE270v01.pdf
You should then calculate the actual responses with the quantized values.
Ideally this could also reflect filter topology at least for direct form
biquads. Response with DF1 with 1st order error shapping would be nice as
well.
This would let you design a filter and actually know how well it will work.
Al Clark
www.danvillesignal.com
Reply by Vladimir Vassilevsky●February 26, 20102010-02-26
Grant Griffin wrote:
> I'm finally about ready to release an IIR filter design program called -
> you guessed it - ScopeIIR (TM).
That's great to hear. One more useful program.
> It currently supports the basic design types of Butterworth, Chebyshev,
> and Elliptic.
Rather then supporting textbook types, it would be good to have design
by brute force optimization, FDLS with optimization of parameters, FDLS
design to minimum phase, linear phase approximation.
> I'm trying to finalize the default and maximum IIR filter
> order that the program will support.
????
Do you have a business plan on charging premium if someone needs
anything different from default or higher then maximum ?
> To help me do that, please tell me
> about your experiences with IIR filter order, assuming the above types
> and implementation via biquads, where applicable:
>
> - Minimum order: (I assume 1)
= 0
> - The typical order you use for most problems
= 2
> - The maximum order you've ever used in a real system
= 64
> - The maximum order that you consider feasible to design using 8-byte
> IEEE floating point ("double")
> - The maximum order that you consider feasible to implement in various
> numeric formats. I'm particularly interested in 8-byte and 4-byte IEEE,
> and any fixed-point formats you've used (please specify).
That entirely depends on the pole/zero positions wrt unit circle; It
would be useful if the program will show what you are getting as far as
design accuracy of the response and the quantization noise floor.
Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com
Reply by Rune Allnor●February 26, 20102010-02-26
On 26 Feb, 15:17, Grant Griffin <nob...@example.com> wrote:
> Rune Allnor wrote:
> > On 26 Feb, 14:23, Grant Griffin <nob...@example.com> wrote:
>
> >> Think of this from the user's and programmer's point of view. �The user
> >> would like to be successful almost all of the time when working within
> >> the specified limitations. �So, the programmer would like to define some
> >> sort of simple limitations which the user will be successful within. �In
> >> that vein, ScopeFIR's Parks-McClellan design is explicitly limited to
> >> 16384 taps even though there is no intrinsic limitation on that
> >> internally - it's just that PM designs often fail with a larger number
> >> of taps.
>
> > So what?
>
> > There could be any number of reasons why any algorithm
> > might fail. A lot of them have to do with the accuracy
> > of the binary represnetation of numbers, while others
> > might have to do with sensitive and/or oversimplified
> > algorithms and what not.
>
> > The statement "PM designs fail for orders larger than N"
> > might rely as much on such implementation-dependent
> > factors, as on any intrinsic property of the algorithm
> > itself.
>
> Hi Rune,
>
> It's good to hear from you. �I guess I should be more specific. �There
> is an unstated premise in my point that I am using 8-byte IEEE
> arithmetic, since ScopeFIR is implemented on Windows using a Microsoft
> compiler that provides that as the most precise floating-point data
> type. �It was not intended as a universal statement for those (few) of
> you who have more precise numeric representations to work with.
Well, I understand that you want to use what resources you have.
But do count in the fact that some of your users will be
concerned about fixed-pt formats, limiting cycles and all
that stuff.
> > Unless you have tested a number of designs and measured
> > statistics to support your claim, I'd suggest you leave
> > the question open.
>
> If it helps, all of this is based on my measurements on the
> aforementioned system. �And that's after I tweaked the Parks-McClellan
> algorithm to work on a larger number of taps - the original
> implementation fails at a much smaller number of taps.
>
> > Instead, implement tests to see if the
> > algorithm converges and / or the design meets the spec.
> > That way you can inform the user about what *actually*
> > happens, without imposing ad hoc restrictions.
>
> I'm not sure that you're thinking of this from the typical user's point
> of view. �
...
> I guess it depends on your intended user. �My products are intended to
> be easy for the novice to use while being highly useful to the seasoned
> pro, on a daily basis.
Those are contardictions in terms. The novice usually wants
something that just works, while the pro every now and then
wants something that pushes the limits.
If you want to serve both, you really need to think very
cautiously. The novice don't want too much leeway; the
pro don't want too many restrictions.
>�Obviously, that's a bit of a balancing act. �So,
> sometimes we have to save the user from himself, though sometimes not.
> For example, I personally feel that any user who creates a FIR with
> 16384 taps should rethink their design - I rarely use more than 256 or
> 512 before going to a multirate design. �However, there might be cases
> where a seasoned pro has reasons to use many thousand. �So I let the
> novice do that, too.
>
> My theory has always been that users prefer something that works
> reliably to something that doesn't, even if the latter has more
> features. �In this case, the feature is the maximum number of taps.
>
> Imagine that Word would let you open a document with an unlimited number
> of pages, but would usually fail if that number of pages was greater
> than 16384. �So the Word folks might set a limit of 16384 pages. �The
> causual user would never have a document with 16384 pages so he would
> never experience this limit. �The seasoned professional who tried to
> open a document with more than 16384 pages and received a message about
> the limitation probably would understand that he should break his
> documents into a set of smaller documents - like the Encyclopedia
> Britannica folks do. ;-)
Once upon a time somebody though that 640 kBytes of RAM
was more than enough for computers...
Rune
Reply by Grant Griffin●February 26, 20102010-02-26
Rune Allnor wrote:
> On 26 Feb, 14:23, Grant Griffin <nob...@example.com> wrote:
>
>> Think of this from the user's and programmer's point of view. The user
>> would like to be successful almost all of the time when working within
>> the specified limitations. So, the programmer would like to define some
>> sort of simple limitations which the user will be successful within. In
>> that vein, ScopeFIR's Parks-McClellan design is explicitly limited to
>> 16384 taps even though there is no intrinsic limitation on that
>> internally - it's just that PM designs often fail with a larger number
>> of taps.
>
> So what?
>
> There could be any number of reasons why any algorithm
> might fail. A lot of them have to do with the accuracy
> of the binary represnetation of numbers, while others
> might have to do with sensitive and/or oversimplified
> algorithms and what not.
>
> The statement "PM designs fail for orders larger than N"
> might rely as much on such implementation-dependent
> factors, as on any intrinsic property of the algorithm
> itself.
Hi Rune,
It's good to hear from you. I guess I should be more specific. There
is an unstated premise in my point that I am using 8-byte IEEE
arithmetic, since ScopeFIR is implemented on Windows using a Microsoft
compiler that provides that as the most precise floating-point data
type. It was not intended as a universal statement for those (few) of
you who have more precise numeric representations to work with.
>
> Unless you have tested a number of designs and measured
> statistics to support your claim, I'd suggest you leave
> the question open.
If it helps, all of this is based on my measurements on the
aforementioned system. And that's after I tweaked the Parks-McClellan
algorithm to work on a larger number of taps - the original
implementation fails at a much smaller number of taps.
> Instead, implement tests to see if the
> algorithm converges and / or the design meets the spec.
> That way you can inform the user about what *actually*
> happens, without imposing ad hoc restrictions.
I'm not sure that you're thinking of this from the typical user's point
of view. However, that's part of my job. Luckily, I'm fairly
pedestrian as far as my DSP design work goes so that isn't too hard for me.
>
> It's not your business, as programmer, to prevent somebody
> who wants to implement a 670 order Elliptic filter in 8-bit
> fixed-point arithemetics from doing so. Just include the
> tests and diagnostics that reports back to the user what he
> *actually* gets. And let the documentation hint at why these
> things happen.
Are you suggesting that users read documentation? ;-)
I guess it depends on your intended user. My products are intended to
be easy for the novice to use while being highly useful to the seasoned
pro, on a daily basis. Obviously, that's a bit of a balancing act. So,
sometimes we have to save the user from himself, though sometimes not.
For example, I personally feel that any user who creates a FIR with
16384 taps should rethink their design - I rarely use more than 256 or
512 before going to a multirate design. However, there might be cases
where a seasoned pro has reasons to use many thousand. So I let the
novice do that, too.
My theory has always been that users prefer something that works
reliably to something that doesn't, even if the latter has more
features. In this case, the feature is the maximum number of taps.
Imagine that Word would let you open a document with an unlimited number
of pages, but would usually fail if that number of pages was greater
than 16384. So the Word folks might set a limit of 16384 pages. The
causual user would never have a document with 16384 pages so he would
never experience this limit. The seasoned professional who tried to
open a document with more than 16384 pages and received a message about
the limitation probably would understand that he should break his
documents into a set of smaller documents - like the Encyclopedia
Britannica folks do. ;-)
On 26 Feb, 14:23, Grant Griffin <nob...@example.com> wrote:
> Think of this from the user's and programmer's point of view. �The user
> would like to be successful almost all of the time when working within
> the specified limitations. �So, the programmer would like to define some
> sort of simple limitations which the user will be successful within. �In
> that vein, ScopeFIR's Parks-McClellan design is explicitly limited to
> 16384 taps even though there is no intrinsic limitation on that
> internally - it's just that PM designs often fail with a larger number
> of taps.
So what?
There could be any number of reasons why any algorithm
might fail. A lot of them have to do with the accuracy
of the binary represnetation of numbers, while others
might have to do with sensitive and/or oversimplified
algorithms and what not.
The statement "PM designs fail for orders larger than N"
might rely as much on such implementation-dependent
factors, as on any intrinsic property of the algorithm
itself.
Unless you have tested a number of designs and measured
statistics to support your claim, I'd suggest you leave
the question open. Instead, implement tests to see if the
algorithm converges and / or the design meets the spec.
That way you can inform the user about what *actually*
happens, without imposing ad hoc restrictions.
It's not your business, as programmer, to prevent somebody
who wants to implement a 670 order Elliptic filter in 8-bit
fixed-point arithemetics from doing so. Just include the
tests and diagnostics that reports back to the user what he
*actually* gets. And let the documentation hint at why these
things happen.
Rune
Reply by Grant Griffin●February 26, 20102010-02-26
steveu wrote:
>> I'm finally about ready to release an IIR filter design program called -
>> you guessed it - ScopeIIR (TM).
>>
>> It currently supports the basic design types of Butterworth, Chebyshev,
>> and Elliptic. I'm trying to finalize the default and maximum IIR filter
>> order that the program will support. To help me do that, please tell me
>> about your experiences with IIR filter order, assuming the above types
>> and implementation via biquads, where applicable:
>>
>> - Minimum order: (I assume 1)
>> - The typical order you use for most problems
>> - The maximum order you've ever used in a real system
>> - The maximum order that you consider feasible to design using 8-byte
>> IEEE floating point ("double")
>> - The maximum order that you consider feasible to implement in various
>> numeric formats. I'm particularly interested in 8-byte and 4-byte IEEE,
>> and any fixed-point formats you've used (please specify).
>
> That seems a slightly odd set of questions. The main driver for word length
> is not the order of the IIR filter, but just how low in the band the poles
> and zeros sit.
>
> Steve
>
Thanks for your input, Steve, but I guess I'm looking for something a
little more concrete. Please note that all of these questions ask for
experiences and opinions rather that an exact mathematical answer. For
example, the question of what is the maximum order that you've ever used
is answerable: what _is_ the maximum order that you've ever used? (I
never thought comp.dsp would be short of unsubstantiated experiences and
opinions. ;-)
Think of this from the user's and programmer's point of view. The user
would like to be successful almost all of the time when working within
the specified limitations. So, the programmer would like to define some
sort of simple limitations which the user will be successful within. In
that vein, ScopeFIR's Parks-McClellan design is explicitly limited to
16384 taps even though there is no intrinsic limitation on that
internally - it's just that PM designs often fail with a larger number
of taps.
Of course, the possibility exists that the user could torture-test
ScopeIIR with an extreme design (either accidentally or on purpose) and
then the design and/or implementation process would fail even within the
specified limits on IIR filter order.
So, I guess I'm looking for parameters that cover the common experience.
For example, the question of what order you have typically used is
needed to fill in a default value of order - which the user can change,
of course. So what might such a default value be? I'm currently using 4.
thanks,
Grant
--
_____________________________________________________________________
Grant R. Griffin
Publisher of dspGuru http://www.dspguru.com
Iowegian International Corporation http://www.iowegian.com
See http://www.iowegian.com/img/contact.gif for e-mail address
Reply by steveu●February 26, 20102010-02-26
>I'm finally about ready to release an IIR filter design program called -
>you guessed it - ScopeIIR (TM).
>
>It currently supports the basic design types of Butterworth, Chebyshev,
>and Elliptic. I'm trying to finalize the default and maximum IIR filter
>order that the program will support. To help me do that, please tell me
>about your experiences with IIR filter order, assuming the above types
>and implementation via biquads, where applicable:
>
>- Minimum order: (I assume 1)
>- The typical order you use for most problems
>- The maximum order you've ever used in a real system
>- The maximum order that you consider feasible to design using 8-byte
>IEEE floating point ("double")
>- The maximum order that you consider feasible to implement in various
>numeric formats. I'm particularly interested in 8-byte and 4-byte IEEE,
>and any fixed-point formats you've used (please specify).
That seems a slightly odd set of questions. The main driver for word length
is not the order of the IIR filter, but just how low in the band the poles
and zeros sit.
Steve
Reply by Grant Griffin●February 25, 20102010-02-25
I'm finally about ready to release an IIR filter design program called -
you guessed it - ScopeIIR (TM).
It currently supports the basic design types of Butterworth, Chebyshev,
and Elliptic. I'm trying to finalize the default and maximum IIR filter
order that the program will support. To help me do that, please tell me
about your experiences with IIR filter order, assuming the above types
and implementation via biquads, where applicable:
- Minimum order: (I assume 1)
- The typical order you use for most problems
- The maximum order you've ever used in a real system
- The maximum order that you consider feasible to design using 8-byte
IEEE floating point ("double")
- The maximum order that you consider feasible to implement in various
numeric formats. I'm particularly interested in 8-byte and 4-byte IEEE,
and any fixed-point formats you've used (please specify).
thanks,
Grant
--
_____________________________________________________________________
Grant R. Griffin
Publisher of dspGuru http://www.dspguru.com
Iowegian International Corporation http://www.iowegian.com
See http://www.iowegian.com/img/contact.gif for e-mail address