Re: [Haskell-cafe] Patterns for processing large but finite streams

2011-07-01 Thread dm-list-haskell-cafe
At Fri, 1 Jul 2011 09:39:32 +0400, Eugene Kirpichov wrote: Hi, I'm rewriting timeplot to avoid holding the whole input in memory, and naturally a problem arises: How to represent large but finite streams and functions that process them, returning other streams or some kinds of aggregate

Re: [Haskell-cafe] Patterns for processing large but finite streams

2011-07-01 Thread Heinrich Apfelmus
Eugene Kirpichov wrote: I'm rewriting timeplot to avoid holding the whole input in memory, and naturally a problem arises: How to represent large but finite streams and functions that process them, returning other streams or some kinds of aggregate values? Examples: * Adjacent differences of

Re: [Haskell-cafe] Patterns for processing large but finite streams

2011-07-01 Thread Eugene Kirpichov
Plain old lazy lists do not allow me to combine multiple concurrent computations, e.g. I cannot define average from sum and length. 2011/7/1 Heinrich Apfelmus apfel...@quantentunnel.de: Eugene Kirpichov wrote: I'm rewriting timeplot to avoid holding the whole input in memory, and naturally a

Re: [Haskell-cafe] Patterns for processing large but finite streams

2011-07-01 Thread Malcolm Wallace
Sure you can. runningAverage :: Int - [Double] - [Double] runningAverage n xs = let chunk = take n xs in (sum chunk / length chunk) : runningAverage (tail xs) Lazy lists are absolutely ideal for this purpose. Regards, Malcolm On 1 Jul 2011, at 07:33, Eugene Kirpichov

Re: [Haskell-cafe] Patterns for processing large but finite streams

2011-07-01 Thread Eugene Kirpichov
I meant the average of the whole list - given a sumS and lengthS (S for Stream), write meanS as something like liftS2 (/) sumS lengthS. Or is that possible with lazy lists too? (looks like arrows actually - which arrow is appropriate here?) 2011/7/1 Malcolm Wallace malcolm.wall...@me.com: Sure

Re: [Haskell-cafe] Patterns for processing large but finite streams

2011-07-01 Thread Alexey Khudyakov
On Fri, Jul 1, 2011 at 12:21 PM, Eugene Kirpichov ekirpic...@gmail.com wrote: I meant the average of the whole list - given a sumS and lengthS (S for Stream), write meanS as something like liftS2 (/) sumS lengthS. Or is that possible with lazy lists too? Sure you can. Sum, length and mean

Re: [Haskell-cafe] Patterns for processing large but finite streams

2011-07-01 Thread Eugene Kirpichov
Alexey, your definition of mean does not look like liftS2 (/) sum length - you have to manually fuse these computations. I'm asking for a formalism that does this fusion automatically (and guaranteedly). 2011/7/1 Alexey Khudyakov alexey.sklad...@gmail.com: On Fri, Jul 1, 2011 at 12:21 PM,

Re: [Haskell-cafe] Patterns for processing large but finite streams

2011-07-01 Thread Alexey Khudyakov
On Fri, Jul 1, 2011 at 12:54 PM, Eugene Kirpichov ekirpic...@gmail.com wrote: Alexey, your definition of mean does not look like liftS2 (/) sum length - you have to manually fuse these computations. Well it was fused for numerical stability I'm asking for a formalism that does this fusion

Re: [Haskell-cafe] Patterns for processing large but finite streams

2011-07-01 Thread Heinrich Apfelmus
Eugene Kirpichov wrote: Plain old lazy lists do not allow me to combine multiple concurrent computations, e.g. I cannot define average from sum and length. I meant the average of the whole list - given a sumS and lengthS (S for Stream), write meanS as something like liftS2 (/) sumS lengthS.

Re: [Haskell-cafe] Patterns for processing large but finite streams

2011-07-01 Thread Eugene Kirpichov
Thanks but I'm afraid that's still not quite what I'm looking for; guess I'll have to define my desire by my implementation - so once it's ready I'll show the result to cafe :) 2011/7/1 Alexey Khudyakov alexey.sklad...@gmail.com: On Fri, Jul 1, 2011 at 12:54 PM, Eugene Kirpichov

Re: [Haskell-cafe] Patterns for processing large but finite streams

2011-07-01 Thread John Lato
From: Eugene Kirpichov ekirpic...@gmail.com Subject: [Haskell-cafe] Patterns for processing large but finite streams To: Haskell Cafe haskell-cafe@haskell.org Message-ID: banlktikdsvq2wv4wjr+qmuvksoav0kt...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi, I'm

Re: [Haskell-cafe] Patterns for processing large but finite streams

2011-07-01 Thread John Lato
After the list discussion, I'm surprised nobody mentioned Max Rabkin/Conal Elliott's blog posts on folds and zips. http://squing.blogspot.com/2008/11/beautiful-folding.html http://conal.net/blog/posts/enhancing-a-zip/ They develop a formalism for zipping functions on lists. Iteratee's `zip` set

Re: [Haskell-cafe] Patterns for processing large but finite streams

2011-07-01 Thread Eugene Kirpichov
Hi, You're right, reifying stream processing functions seems indeed the way to go - and that looks even more like arrows :) I thought of something like this: data SP i o = Yield [o] (Maybe (Maybe i - SP i o)) Scalar functions like sum and length are just SP's that return a single item in the

Re: [Haskell-cafe] Patterns for processing large but finite streams

2011-07-01 Thread Ketil Malde
Eugene Kirpichov ekirpic...@gmail.com writes: 2011/7/1 Heinrich Apfelmus apfel...@quantentunnel.de: Eugene Kirpichov wrote: I'm rewriting timeplot to avoid holding the whole input in memory, and naturally a problem arises: Plain old lazy lists? Heretic! :-) I generally have written a

Re: [Haskell-cafe] Patterns for processing large but finite streams

2011-07-01 Thread Erik Hesselink
This sound exactly like what attribute grammars, like the system developed at Utrecht University [1], are useful for. Erik [1] http://www.cs.uu.nl/wiki/HUT/AttributeGrammarSystem On Fri, Jul 1, 2011 at 10:54, Eugene Kirpichov ekirpic...@gmail.com wrote: Alexey, your definition of mean does not

[Haskell-cafe] Patterns for processing large but finite streams

2011-06-30 Thread Eugene Kirpichov
Hi, I'm rewriting timeplot to avoid holding the whole input in memory, and naturally a problem arises: How to represent large but finite streams and functions that process them, returning other streams or some kinds of aggregate values? Examples: * Adjacent differences of a stream of numbers *