April 2004 - Haskell-Cafe

Audio signal processing in Haskell
by Henning Thielemann 02 Jul '04

02 Jul '04

As I can see a question similar to mine was already raised here: http://www.haskell.org/pipermail/glasgow-haskell-users/2004-February/006305… I also encountered the elegance that Haskell's laziness provides for signal processing. I use lists for the signals. With help of Haskore I put together a small song and it needed 5 minutes for rendering the quite simple music of about 30 seconds. Don't care about the exact numbers but I find it rather slow. What is the most promising strategy to speed up the computation without loosing the elegance of Haskell's lists? 1. Upgrading GHC from 6.0 to the current version? 2. Use of simplification rules? How can I find out what new rules may be useful? The several dumps that GHC can generate are a bit hard to understand. :-( Is there some more detailed information about what rules GHC already applies than what one can get with -ddump-simpl-stats and -ddump-rules? 3. More strictness? Is a custom list structure with strict entries and maybe with only one constructor (thus always infinite) a considerable alternative? This would disallow the use of lots of functions that deal with lists, including State monad functions. 4. A list of arrays? Then signal processes with feedback like an echo are much more difficult.

2 3

Is it possible to read existential types?
by S. Alexander Jacobson 29 Apr '04

29 Apr '04

Is is possible to read/show an existentially typed list? Would it be possible if, instead of using read/show, I defined some variant that relies on the typeof/typeable infrastructure? Is there a way to read in a typename for use in coercing a read? -Alex- _________________________________________________________________ S. Alexander Jacobson mailto:me@alexjacobson.com tel:917-770-6565 http://alexjacobson.com

4 8

Re: sizeFM type
by Tomasz Zielonka 28 Apr '04

28 Apr '04

On Mon, Apr 26, 2004 at 08:43:44PM -0400, ajb(a)spamcop.net wrote: > > And re sizeFM, I would note that Google has more > > than 2^31 pages indexed in memory. > > I would note, in addition, that they don't have that many pages indexed > on a single machine. Almost nobody has a database with that many records > on a single machine, even those who have clusters of 64 bit machines. It seems I qualify as almost nobody, cause I've had a database with more than 2^34 records on a single IA32 machine. However, I wouldn't ever think of loading the entire database to RAM. Best regards, Tom -- .signature: Too many levels of symbolic links

5 6

Re: [Haskell-cafe] Re: sizeFM type
by S. Alexander Jacobson 27 Apr '04

27 Apr '04

On Tue, 27 Apr 2004, Tomasz Zielonka wrote: > The data you provided is interesting. However, if I had such a machine, > my work could be much less challenging :) I would note that people today are making strenuous efforts to retain compatibility with a Haskell98 standard that it only 6 years old! If we are making choices intended to have a lifetime of e.g. 10 years (see <http://www.joelonsoftware.com/articles/fog0000000017.html>), then I would observe that the 24gb machine I specced out will, assuming Moore's law lasts, cost only $2k in 5-6 years. The Sun Fire 15k with 288GB of memory and 72 Sparcs (think GPH!), that today costs $2.6m will cost only $155k. Note, since you don't need 72 CPUs, you'll probably be able to get this machine for <$50k. So, perhaps the question here is: What is the planned lifetime of sizeFM? Do we prefer the safety of knowing our code will work at arbitrary scale or the ecstacy of having it run fast today? Put differently, would you rather cope with hardware limitations today or software limitations tomorrow? -Alex- _________________________________________________________________ S. Alexander Jacobson mailto:me@alexjacobson.com tel:917-770-6565 http://alexjacobson.com

1 0

Re: [Haskell] Re: sizeFM type
by Ketil Malde 27 Apr '04

27 Apr '04

[Moved to -cafe at SPJ's request] "Serge D. Mechveliani" <mechvel(a)botik.ru> writes: > On Mon, Apr 26, 2004 at 10:09:18PM +0200, Ketil Malde wrote: >> "Serge D. Mechveliani" <mechvel(a)botik.ru> writes: >>> length :: [a] -> Integer >>> smallLength :: [a] -> Int >> Hmm...isn't it possible to use a class here? Perhaps even Num? > I think, for many functions, like length, it is most natural to > return Integer only. Well, perhaps Integral is a better choice. I was perhaps thinking of functions like: average xs = sum xs / length xs I'd rather have a polymorphic "length", than different versions for each possible return type. One problem could be that with average xs = sum xs / fromIntegral (length xs) the return type of length becomes ambigous? -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

Data constructors
by Mark Carroll 26 Apr '04

26 Apr '04

I keep running into annoyance in having to name data constructors differently if they're for different types if they're in the same module or something. I wish that something like some Type.Constructor syntax worked in order to disambiguate. Or, better still, I have that problem with function names too (e.g. Data.List.union, Data.Set.union, IIRC) and it occurs to me that a lot of this can be resolved automatically because the types only make sense with one of the choices. I'm not really proposing any changes; more, I'm wondering what others' thinking is about this sort of thing - what annoys them, how they get around it, etc. -- Mark

4 4

Hierarchical Library
by haskell＠alias.spaceandtime.org 24 Apr '04

24 Apr '04

Hello, Why does this fail? ========================== import System.Posix test = Temp.mkstemp ========================== Are the libraries hierarchical in name only? Thanks, James

2 2

FiniteMap, Map, FiniteSet, Set
by haskell＠alias.spaceandtime.org 24 Apr '04

24 Apr '04

Here's a really elementary question: Why does the library have [FiniteMap and Set] instead of [FiniteMap and FiniteSet] or just [Map and Set]? Is there some reason for this inconsistency? Thanks, James

3 2

Syntax for modifying nested product types
by Mark Carroll 23 Apr '04

23 Apr '04

I have data objects where each component is a labelled field through which I access or modify it. I have a hierarchy of these - many of the fields are themselves such data objects, so I may need to apply a few selector functions to get down to what I want (call these "deep"). For fairly flat things, the updates using field labels are okay. However, when I have a function that needs to tweak various bits of various "deep" fields, based on various conditions, then it gets really ugly, not least because of the conditions: foo { bar = baz } becomes, let old = bar foo in foo { bar = if cond then f old else old } or whatever. Do I need such a let for each component and sub-component of the object that has a child that may be modified, or will foo { bar = if cond then f (bar foo) else bar foo } be suitably optimised? (The if's inside the {} because there may be multiple fields (or children thereof) being modified based on different conditions.) -- Mark

6 5

Re: [Haskell-cafe] Splitting a list
by Steve Schafer 23 Apr '04

23 Apr '04

On Wed, 21 Apr 2004 14:57:57 +0100, you wrote: >How about implementing a directly recursive solution? Simply >accumulate the sum so far, together with the list elements you have >already peeled off. Once the sum plus the next element would exceed >the threshold, emit the accumulated elements, and reset the sum >to zero. > > splitlist threshold xs = split 0 [] xs > where > split n acc [] = reverse acc: [] > split n acc (x:xs) > | x >= threshold = error (show x++" exceeds threshold ") > | n+x > threshold = reverse acc : split 0 [] (x:xs) > | otherwise = split (n+x) (x:acc) xs Thanks. Apart from a small off-by-one problem (the "x >= threshold" test needs to be "x > threshold" instead), it works fine. I had actually started along those lines, but got bogged down in the details of passing the accumulator around, and ended up painting myself into a corner, so I abandoned that approach (prematurely, as it turns out). And thanks to everyone else who replied--I don't want to clutter the list with a lot of individual replies. As you can probably tell, I've only recently begun playing with Haskell, and the process of reconfiguring my neurons into recursive loops has not yet been completed. -Steve

1 0