[Haskell-cafe] How to implement digital filters using Arrows
John Lask
jvlask at hotmail.com
Mon Oct 31 23:19:02 CET 2011
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
>
>
More information about the Haskell-Cafe
mailing list