[Haskell-cafe] How to implement a digital filter, using Arrows?
capn.freako at gmail.com
Thu Oct 20 05:07:23 CEST 2011
One more question on the `runAuto' code, John:
If I understand the code correctly, `f' is an arrow. Yet, we're using
it on the right side of `=' in a simple assignment. How are we getting
away with that?
On Wed, Oct 19, 2011 at 3:02 PM, John Lask <jvlask at hotmail.com> wrote:
> On 20/10/2011 5:11 AM, Captain Freako wrote:
> for your use case then, the StateArrow seems more appropriate as it provides
> you with the final state. Ofcourse the Automaton arrow could also be used:
>> liftAu' f s0 = proc x -> do
>> rec (y,s') <- arr f -< (x,s)
>> s <- delay s0 -< s'
>> returnA -< (y,s)
> this explicitly returns the state with evry value. However, you then need to
> manually thread the state through.
> note: the arrow "plumbing" is only used when you start composing filters,
> with arrow combinators. If your not doing any composition as
> such then lifting your functions into the "arrows" is not buying you much.
>> John Lask wrote:
>>> This is literate code. It expounds on your initial question and provides
>>> two solutions based either on the StateArrow or Automaton....
>>> (Remainder omitted.)
>> Thanks so much for your help!
>> I'm going to study your example code and try to understand how the
>> Automaton implicit plumbing is being used.
>> (I'm determined to get my head around this arrow concept, damn it! ;-) )
>> I wonder if I might pester you for the final piece of the puzzle here:
>> When the processing of the input stream through the filter is
>> complete, I need to pass the final filter state, along with the output
>> stream, back to the calling program.
>> (This is because the calling program is going to split the input
>> signal into conveniently sized chunks, calling my filter routine
>> several times, in order to process the entire input stream. It expects
>> to be able to pass an initial filter state into my routine, which is
>> just the final state of the filter that I passed back to it after the
>> previous call. In this way, we avoid inserting any edge artifacts at
>> the input stream segmentation boundaries.)
>> So, is it possible to `fetch' the final state out of that Automaton,
>> when it's finished processing the input list?
More information about the Haskell-Cafe