I think I've got a handle on this now. As you said, xb4 spirals out of control, so there are a couple of clamping factors that reduce xb4, hopefully below a threshold where it is stable.

It is of course, unstable if the frequency is <0 or >1 (where 1 is the Nyquist frequency) but there is a "safe" mode

I'm going to give it a try with this filter and see if any of my colleagues can break it :)

Ed
 
Gemnotes-0.1alpha: Live music notation for Pure Data
http://sharktracks.co.uk/

From: Peter Brinkmann <peter.brinkmann@googlemail.com>
To: Ed Kelly <morph_2016@yahoo.co.uk>
Cc: PD List <pd-list@iem.at>
Sent: Saturday, 24 March 2012, 15:08
Subject: Re: [PD] [PD-dev] Filter design for iPhone

On Sat, Mar 24, 2012 at 5:20 AM, Ed Kelly <morph_2016@yahoo.co.uk> wrote:
> My mistake
>
>> Ah.
>> As often happens, as soon as I have pressed "send" and posted the
>> question, the answer pops out.
>> xb4 = xb4 - xb4 * xb4 * xb4 * 0.166667f;
>>
>> is replaced by...
>>
>> xb4 = xb4 - xb4 * xb4 * xb4 * 0.01f;
>>
>> ...and it works.
>
> and then breaks again

Inf - Inf is NaN.  If the value of xb4 spirals out of control, that
may happen here.  That would also explain why it takes longer to fail
when you reduce the last factor.

>
> Gemnotes-0.1alpha: Live music notation for Pure Data
> http://sharktracks.co.uk/
> ________________________________
> From: Ed Kelly <morph_2016@yahoo.co.uk>
> To: Mathieu Bouchard <matju@artengine.ca>
> Cc: PD List <pd-list@iem.at>; Joe White <joe@rjdj.me>; pddev <pd-dev@iem.at>
> Sent: Saturday, 24 March 2012, 8:47
> Subject: Re: [PD-dev] [PD] Filter design for iPhone
>
>>> I'm anxious to know what limit is reached in the coefficients of the
>>> filter that causes the undefined result (NaN).
>>
>>I haven't seen the code, but I just want to make you notice that adding
>> together -Infinity and +Infinity results in a NaN ; so does subtracting
>>two infinities of the same sign.
>>
>>So, the NaN might happen when two expressions that are supposed to
>> partially cancel each other, happen to both overflow, in different
>> directions.
>>
>>There are various possible causes for NaN, but with formulas that only
>> involve +, - and *, the possibilities are a lot more limited.
>
> Hmmm.
> I think that's why it puzzles me so. Can you see a / anywhere here?
>
>   while (n--) {
>     i1=(*in++);
>     fc1 = (*fc++);
>     res1 = (*res++);
>     q = 1.0f - fc1;
>     p = fc1 + 0.8f * fc1 * q;
>     fcoeff = p + p - 1.0f;
>     q = res1 * (1.0f + 0.5f * q * (1.0f - q + 5.6f * q * q));
>     i1 -= q * xb4;
>     t1 = xb1;
>     xb1 = (i1 + xb0) * p - xb1 * fcoeff;
>     t2 = xb2;
>     xb2 = (xb1 + t1) * p - xb2 * fcoeff;
>     t1 = xb3;
>     xb3 = (xb2 + t2) * p - xb3 * fcoeff;
>     xb4 = (xb3 + t1) * p - xb4 * fcoeff;
>     xb4 = xb4 - xb4 * xb4 * xb4 * 0.166667f;
>     xb0 = i1;
>     *out++ = xb4;
>  }
>
> No reciprocals, no divisions, just +,-,*.
> I cannot help thinking I must be reaching a "limit" in the calculus sense...
>
> Ed
>
>
>
>
> ______________________________________________________________________
> | Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev@iem.at
> http://lists.puredata.info/listinfo/pd-dev
>
>
>
>
>
> _______________________________________________
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>