October 2007 - Haskell-Cafe

Why can't Haskell be faster?
by Paulo J. Matos 01 Nov '07

01 Nov '07

Hello all, I, along with some friends, have been looking to Haskell lately. I'm very happy with Haskell as a language, however, a friend sent me the link: http://shootout.alioth.debian.org/gp4/ which enables you compare several language implementations. Haskell seems to lag behind of Clean. >From what I've seen of Clean it seems almost like Haskell. It even distributes a Haskell->Clean translator so the obvious question is, why is Haskell slower? Being similar languages and being GHC a very good compiler, can't it get at least as fast as Clean? What am I missing here? (I wrote this mail assuming the results from the URL are trustworthy). Cheers, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK

10 13

Haskell libraries for computer vision
by Don Stewart 01 Nov '07

01 Nov '07

http://alberrto.googlepages.com/easyvision "An experimental Haskell system for fast prototyping of computer vision and image processing applications." Looks ridiculously cool. -- Don

4 3

Re: Why can't Haskell be faster?
by david48 31 Oct '07

31 Oct '07

I'd like to see Supero and Jhc - compiled examples in the language shootout.

1 0

Type inference problem with division (/)
by noa 31 Oct '07

31 Oct '07

Hi! I have the following function: theRemainder :: [String] -> [String] -> Double theRemainder xs xt = sum( map additional (unique xs) ) where additional x = poccur * (inf [ppos,pneg]) --inf takes [Double] where xsxt = zip xs xt pi = countPos xr -- countPos returns an Int ni = (length xr) - pi len = length xs len2 = length xr ppos = pi/len2 -- THESE ARE THE PROBLEM pneg = ni/len2 -- THESE ARE THE PROBLEM poccur = (pi+ni)/len xr = (filter ((\y -> (fst y)==x)) (xsxt)) And I am getting this error message with ghc: matrix.hs:54:31: Couldn't match expected type `Double' against inferred type `Int' In the expression: ppos In the first argument of `inf', namely `[ppos, pneg]' In the second argument of `(*)', namely `(inf [ppos, pneg])' How can I change the declaration of ppos nad pneg so they are treated as Double for the inf function? Cheers, Nick -- View this message in context: http://www.nabble.com/Type-inference-problem-with-division-%28-%29-tf472211… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

5 5

does the order of splice definitions matter in template haskell, or is this a bug?
by Thomas Hartman 31 Oct '07

31 Oct '07

I have a situation where ... stuff... $(expose ['setState, 'getState] f = SetState compiles but f = SetState $(expose ['setState, 'getState] doesn't compile, with error: Not in scope: data constructor 'SetState. Is this a bug? expose is defined in HAppS.State.EventTH t,. --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

3 2

help needed packaging curl bindings
by brad clawsie 31 Oct '07

31 Oct '07

i have decided to take on the task of packaging-up (for hackage) and documenting the curl bindings as available here: http://code.haskell.org/curl/ if the originators of this code are reading this and do not wish me to proceed please say so, i won't be offended otherwise i was wondering if people had good examples to point me to for providing the cross-platform support needed for a FFI-based module such as this. i have made the necessary changes to compile the code on freebsd, but for other platforms i am not sure at all, particularly non-unix style platforms like windows. my guess is that providing cross-platform support requires autoconf etc prior to the hackage build process (?) any info/references appreciated thanks brad

2 3

Re: [Haskell-cafe] Why can't Haskell be faster?
by manu 31 Oct '07

31 Oct '07

>> From what I've seen of Clean it seems almost like Haskell. It even >> > distributes a Haskell->Clean translator so the obvious question is, > why is Haskell slower? > It's also something I've wondered about, and I'm curious about the answer... One of the differences between Haskell and Clean is how side-effects are allowed (Uniqueness Types for Clean, and Monadic I/O for Haskell) GHC also supports a lot of extensions beyong Haskell98. Does it explain the difference in performances ? I don't know... Experts please ! Manu

1 0

Re[2]: [Haskell] Image manipulation
by Bulat Ziganshin 31 Oct '07

31 Oct '07

Hello Bjorn, Wednesday, October 31, 2007, 11:54:33 AM, you wrote: > data fields. Data Field Haskell had a function to force the evaluation of > all elements in a data field at once. this looks like a parallel arrays? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Re: [Haskell-cafe] Strictness leak
by Jeff Polakow 31 Oct '07

31 Oct '07

I forgot to send this reponse to haskell-cafe earlier... Hello, > You mean for the IO monad, right? > Sorry. I meant divergence is unavoidable for any strict Monad, such as IO. However, sequence will always compute over the entire list; if the resulting computation itself is lazy then the result can be inspected lazily. > take 10 $ execWriter $ sequence $ repeat $ tell ([3]::[Int]) > This is a good example. Note that the computation of sequence itself is infinite. snd $ runWriter $ sequence (repeat $ tell [3]) >>= return . take 10 will result in an infinite list, but fst $ runWriter $ sequence (repeat $ tell [3]) >>= return . take 10 will return a 10 element list. -Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

1 0

Re: [Haskell] Image manipulation
by Dan Piponi 30 Oct '07

30 Oct '07

Jerzy, There is a simple framework for performing filtering operations on images lazily: http://sigfpe.blogspot.com/2006/12/evaluating-cellular-automata-is.html (Scroll down to the 2D example in the comments.) 2D digital filters lend themselves nicely to a comonadic framework though you probably have to drop the comonads for operations other than convolution type things. And you're right, doing this lazily at the pixel level is expensive. However, if we replace pixels with 256x256 blocks, say, where the blocks themselves are strict but the images are lazily made up of blocks, then we have the potential for a nice and efficient image processing library that inherits its laziness directly from Haskell. On 10/30/07, jerzy.karczmarczuk(a)info.unicaen.fr <jerzy.karczmarczuk(a)info.unicaen.fr> wrote: > Dan Piponi adds to a short exchange: > > > jerzy.karczmarczuk: > >> [iso-8859-1] Bj�rn Wikstr�m writes: > >> > >> > Hi! I have lots and lots of images (jpegs) that I would like to manipulate > >> > and shrink (in size). They are around 5 Mb big, so I thought this would > >> > be a good Haskell project since it's a lazy evaluating language. > >> ... > >> I must say that I don't see much use of laziness here. > > > Laziness plays a big role in real world image processing. Typically, > > in applications like Apple's Shake, you build a dataflow > > representation of the image processing operations you wish to perform, > > and the final result is computed lazily so as to reduce the amount of > > computation. For example, if you blur an image, and then zoom in on > > the top left corner, then only the top left corner will be loaded up > > from the original image (assuming your image file format supports > > tiled access). You still work on tiles or scan-lines, rather than > > individual pixels, so the laziness has a 'coarse' granularity. > > > > But I'm not sure if this is what the original poster was talking about. > > I am neither... > Still, Dan, I think that there is quite a difference between incremental > processing of signals, and images, etc., and the *lazy evaluation* of > them. Of course, a stream is consumed as economically as it can, but > not less. If you filter an image (shrinking, so some low-pass MUST be > done), a pixel must be loaded with its neighbourhood, which means *some* > scan lines. > With a JPEG this means that a 8x8 block should be loaded also with its > vicinity. But would you suggest that individual pixel processors should > be lazy? It would be useless, and probably resulting in some penalties. > > So, the laziness of Haskell for me here is less than useful. > Noooow, the lazy *generation* of streams is another story... > Generating music (low level, i.e. sound patterns) through lazy algorithms > is quite interesting. > > Jerzy Karczmarczuk > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

1 0