[Haskell-cafe] How to implement digital filters using Arrows

[John Lask]

On 1/11/2011 1:35 AM, Captain Freako wrote:

you need to study ArrowLoop and understand that. In the code

rec (y,s')<- arr f -<  (x,s)
     s<- delay s0 -<  s'

the state is 'captured' in the recursive binding. i.e. just like in real 
circuits the output state "s" is threaded back as an input.

The recursive binding is just sugar for the application of the loop 
combinator. The signature of the loop combinator is

loop :: arrow (input, feedback) (output, feedback) -> arrow input output

with the loop combinator (with which recursive arrow bindings are 
defined) the function could have been defined as...

liftAu f s0 = loop (second (delay s0) >>> arr f )

the delay is neccessary to break the recursion. i.e. to calculate the 
next output and state the previous state is used.

>
>   >  liftAu :: ((x,FilterState s)->(y,FilterState s)) ->  FilterState s ->
> FilterAu x y
>   >  liftAu f s0 = proc x ->  do
>   >     rec (y,s')<- arr f -<  (x,s)
>   >         s<- delay s0 -<  s'
>   >     returnA -<  y
>
>
>
> I think I understand how the `returnA' in the last line of your
> `liftAu' function is getting translated by those instance definitions
> into:
>
> c where
> c = Automaton ( arr id&&&  arr (const c) )
>
> and, furthermore, how that is passing the supplied `y' into the first
> element of the resulting couple. However, I don't understand how the
> recursively defined `c' is capturing the modified filter state and
> preserving it for the next call. It seems like the Automaton being
> referred to by `c' is a newly constructed entity, which knows nothing
> about the current state of the running Automaton.
>
> Any help in understanding this would be greatly appreciated.
>
> Thanks!
> -db
>
>