September 2010 - Beginners

Installing package hsc3 – Haskell supercollider
by Deb Midya 17 Sep '10

17 Sep '10

Hi Haskell Users, Thanks in advance. I am using Haskell on Windows XP. I have downloaded HaskellPlatform-2010.2.0.0-setup.exe and installed it. I have checked that GHCi version is 6.12.3. May I request you to assist me for the following please: To install Haskell supercollider package, I have downloaded hsc3-0.7.tar.gz. How can I install this package now? Is there any document (how to use) on this package? To assist me for this, I have also checked that whether cabal is working or not. To do that: At dos prompt: \ghc>cabal –help \ghc> cabal install –help It shows me flags for help and installation. Once again, thank you very much for the time you have given. Regards, Deb

2 1

Re: [Haskell-beginners] Padding List with Zeros
by Hein Hundal 16 Sep '10

16 Sep '10

On Wed, 15 Sep 2010 16:23:49, Daniel Fischer wrote: > On Wednesday 15 September 2010 15:15:49, Henry Olders wrote: > > On 2010-09-14, at 19:35 , Lorenzo Isella wrote: > > > Dear All, > > > I still have to find my way with immutable lists and list > > > comprehension. Consider the following lists > > > > > > A=[0,10,20,30,40,50] > > > B=[0,10,50] (i.e. B is a subset of list A; list A is > > > already ordered in increasing order and so is B). > > > C=[2,1,-5] i.e. there is a corresponding element in C for every > > > element in B. > > > > > > Now, I would like to define a new list D having length equal > > > to the length of A. The elements of D in the position of the > > > elements of A in common with B are equal to the corresponding > > > entries in C, whereas the other ones are zero i.e. > > > D=[2,1,0,0,0,-5]. How can I achieve that? The first thought > > > that comes to my mind is to define a list of zeros which I > > > would modify according to my needs, but that is not allowed... Yes, that is not allowed. First thing I thought of also. > > > Many thanks > > > > > > Lorenzo > > > > Being a real Haskell newby, I can figure out a one-line solution in > > Python, but I don't know how to do something similar in Haskell, or even > > if it's possible. Please correct me if I'm wrong, but there does not > > seem to be a dictionary type in Haskell, and I am not aware of how to > > specify an inline if...else inside a list comprehension. I would really > > appreciate it if someone could show me how to do something similar to > > this Python statement in Haskell. > > > >import Data.Maybe > > > >>> A=[0,10,20,30,40,50] > > >>> B=[0,10,50] > > >>> C=[2,1,-5] > > These have to be lowercase in Haskell, of course :) > > > >>> [dict(zip(B,C))[a] if a in B else 0 for a in A] > > map (fromMaybe 0 . (`lookup` zip b c)) a > > or, as a list comprehension, > > [fromMaybe 0 (lookup v dic) | let dic = zip b c, v <- a] > > Slightly more verbose than the Python. > > But this doesn't deal with multiple entries (istr that was > mentioned previously in this thread), for > > a = [0, 10, 10, 20, 30 , 40, 50] > b = [0, 10, 10, 50] > c = [2, 1, 3, -5] > > neither would produce > > [2, 1, 3, 0, 0, 0, -5] > > which I believe would be the desired behavior. > > > > > [2, 1, 0, 0, 0, -5] > > > > Henry I love the map solution and the lookup solutions--very concise. Someday perhaps those will occur to me when I look at these problems. Here is my (extremely) verbose beginner solution. I think this solution is linear time and it returns the "desired behavior" in Daniel's post. -- indices v1 v2 -- find the elemIndex of v2's elements in v1 -- almost equivalent to (map (flip elemIndex v1) v2) -- indices v1 v2 = indices' 0 v1 v2 indices' iOff (x:xs) (y:ys) | x < y = indices' (iOff+1) xs (y:ys) | x ==y = iOff:(indices' (iOff+1) xs ys) | x > y = error "indicies:: elem not found" indices' _ _ [] = [] indices' _ [] (y:ys) = error "indices:: elem not found" -- makevec 0 indices values -- returns a vector with values filled in at the indices given -- makevec _ [] _ = [] makevec _ _ [] = error "makevec:: " makevec iOffSet (i:is) (x:xs) | iOffSet < i = replicate (i-iOffSet) 0 ++ makevec i (i:is) (x:xs) | iOffSet ==i = x:(makevec (iOffSet+1) is xs) | iOffSet > i = error "makevec error" hisfunc :: [Integer] -> [Integer] -> [Integer] -> [Integer] hisfunc a b c = let front = makevec 0 (indices a b) c in front ++ replicate (length a - length front) 0 test1 = hisfunc a b c test2 = hisfunc (a++[70, 90]) b c test3 = hisfunc (a++[70, 90]) (b++[70]) (c++[-14]) test4 = hisfunc [0,10,10,20,30,40,50] [0,10,10,50] [2,1,3,-5]

3 2

Capture stdout from a command on Windows
by David Frey 16 Sep '10

16 Sep '10

Hi, I'm trying to capture the output (stdout) of a command on Windows. This is what I have so far: import System.Process (runProcess, waitForProcess) import System.IO (hGetContents) executeCapturingStdout :: String -> String -> IO [String] executeCapturingStdout cmd workingDir = do let stdoutHandle = -- TODO: What do I put here? processHandle <- runProcess cmd [] (Just workingDir) Nothing Nothing stdoutHandle Nothing exitCode <- waitForProcess processHandle content <- hGetContents stdoutHandle return lines content I have tried searching on google and I haven't been able to find an answer yet. Thanks, Dave

3 2

Re: [Haskell-cafe] try, seq, and IO
by Jeroen van Maanen 16 Sep '10

16 Sep '10

Op 2010-09-15 18:38, Neil Brown schreef: > On 15/09/10 10:13, Jeroen van Maanen wrote: >> The past year I have been working on a port of my machine learning project named LExAu from Java to Haskell. I'm still very glad I took the jump, because the complexity curve appears to be log shaped rather than exp shaped. In one year I almost got to the functionality that had taken me five years to produce in Java (of course it helped a lot that I had a working prototype this time). >> >> There is one thing that still bothers me though: when I write seq or $! it doesn't seem to have any effect! >> >> Currently I am trying to add some exception handling to help me debug the system, but the code that I managed to produce depends on the logging statement to produce the desired result. :-( It looks like this, and only works when I uncomment the line '-- logger "Check sum": [...]', otherwise the exception is caught by the try around the body of the thread that this code runs in: >> >> do logger "Received update" [showString label, logs update] >> result<- >> try $! >> do maybeUpdatedModel<- return $ f update startModel >> theCheckSum<- return $ liftM checkSum maybeUpdatedModel >> -- logger "Check sum" [showString label, shows theCheckSum] >> return $! seq theCheckSum maybeUpdatedModel >> maybeNextModel<- >> case result of >> Right theMaybeNextModel -> return theMaybeNextModel >> Left exception -> >> do let exc :: SomeException >> exc = exception >> logger "Exception" [showString label, shows exception] >> return Nothing >> logger "Maybe next model" [showString label, logs maybeNextModel] >> >> For more context see: >> >> http://lexau.svn.sourceforge.net/viewvc/lexau/branches/totem/src/LExAu/Pipe… >> >> after line 241. >> >> Can someone explain why a few showStrings a shows and a putStrLn are more effective in forcing the check sum to be computed (which necessarily evaluates the complete updated model and reveals the lurking exception) than the seq on the line just below the logging statement? >> > I just looked at your code for a second time and I think I know. Here's my guess: > > It's all about the types, and weak head normal form. The "theCheckSum" item has type Maybe a, and you are looking for an exception in the "a" part that's wrapped by Maybe (I presume: the Just/Nothing is determined by the function "f", not "checkSum"). When you use seq or $!, you only evaluated to weak head normal form, For something of type "Maybe a", that's only the Just/Nothing part. Forcing that aspect to be evaluated only requires some evaluation of the function "f", and the checkSum function doesn't need to be applied, even if it is a Just value. However, your shows function digs deeper and evaluates the whole thing, so hence it will trigger the error where seq and $! won't. Ah, I didn't know that weak normal form evaluation doesn't force the evaluation of the argument of the Just constructor. That makes sense. (I confess that I added the liftM construction almost without thinking when the compiler told me that I couldn't just ask for the checkSum of maybeUpdatedModel and had not realized that this changed the type of theCheckSum. I also stubbornly ignored the telltale "Just" in the log statement.) > So, if I'm right, you need to change your function to make sure to evaluate the checksum itself. The deepseq package on Hackage may help here (use the deepseq function in place of seq: http://hackage.haskell.org/packages/archive/deepseq/1.1.0.0/doc/html/Contro…) The maybe function does the trick quite neatly. In fact, I added the checkSum method because my particular data stuctures have quite natural Integer valued functions that force evaluation of the complete, ... erm, in Java I would have said object graph, ... you know, ... everything. ;-) > I'm a little suspicious of the code as a whole though: why does checkSum throw an exception rather than returning a Maybe value? Or is it an exception somehow outside of your control? That is because the exception is thrown by an assert kind of thing. There are still bugs lurking in the code (strange, I have been so careful ;-> ), but I don't want to litter my code with Maybe types just in case there Maybe something wrong with it. I use Maybe frequently, for example, when a function may or may not return an updated data structure when given some extra information, but in those cases it is natural in the context of the algorithm to use a Maybe type. > Another thing: > > x <- return $ blah > > in a do block is bad style, and can always be replaced with: > > let x = blah > > Note that there is no "in" needed with let statements in do blocks (that confused me when first learning Haskell). That's funny, first I fixed my code: do let maybeUpdatedModel = f update startModel theCheckSum <- return $ maybe 0 checkSum maybeUpdatedModel return $! seq theCheckSum maybeUpdatedModel That worked beautifully. The exception is caught here as desired. Then I tried to get rid of the remaining '<- return'. However, when I write: do let maybeUpdatedModel = f update startModel theCheckSum = maybe 0 checkSum maybeUpdatedModel return $! seq theCheckSum maybeUpdatedModel It reverts to the old behavior. What is the subtle difference here? And let me guess, the next step is to replace do let blah blah return result by return $ let blah blah in result Right? Cheers, Jeroen

1 1

try, seq, and IO
by Jeroen van Maanen 15 Sep '10

15 Sep '10

The past year I have been working on a port of my machine learning project named LExAu from Java to Haskell. I'm still very glad I took the jump, because the complexity curve appears to be log shaped rather than exp shaped. In one year I almost got to the functionality that had taken me five years to produce in Java (of course it helped a lot that I had a working prototype this time). There is one thing that still bothers me though: when I write seq or $! it doesn't seem to have any effect! Currently I am trying to add some exception handling to help me debug the system, but the code that I managed to produce depends on the logging statement to produce the desired result. :-( It looks like this, and only works when I uncomment the line '-- logger "Check sum": [...]', otherwise the exception is caught by the try around the body of the thread that this code runs in: do logger "Received update" [showString label, logs update] result <- try $! do maybeUpdatedModel <- return $ f update startModel theCheckSum <- return $ liftM checkSum maybeUpdatedModel -- logger "Check sum" [showString label, shows theCheckSum] return $! seq theCheckSum maybeUpdatedModel maybeNextModel <- case result of Right theMaybeNextModel -> return theMaybeNextModel Left exception -> do let exc :: SomeException exc = exception logger "Exception" [showString label, shows exception] return Nothing logger "Maybe next model" [showString label, logs maybeNextModel] For more context see: http://lexau.svn.sourceforge.net/viewvc/lexau/branches/totem/src/LExAu/Pipe… after line 241. Can someone explain why a few showStrings a shows and a putStrLn are more effective in forcing the check sum to be computed (which necessarily evaluates the complete updated model and reveals the lurking exception) than the seq on the line just below the logging statement? Cheers, Jeroen

1 0

A question on seq
by Klaus Gy 15 Sep '10

15 Sep '10

Hi! Inspred from the discussion http://www.haskell.org/pipermail/beginners/2010-February/003396.html , I just try to understand the seq function a bit better. When I compare these two functions: firstSum :: Num a => a -> [a] -> a firstSum s [] = s firstSum s (x:xs) = seq help (firstSum help xs) where help = x + s secondSum :: Num a => [a] -> a secondSum [] = 0 secondSum (x:xs) = seq help (x + help) where help = secondSum xs What should be the difference? In my opinion both functions do not return a complete unevaluated thunk (secondSum returns a thunk of the form (THUNK + b) where THUNK contains a single numeral value). But it seems to me that the first function computes the output somehow linear in the sense that it does just a set of substitutions while the second functions has to create a tree to handle all the recursive calls of seq (sorry, my terminology is for sure a bit poor). So I would say the first function delivers a better performance. (In the discussion I mentioned, the second function was not discussed in this form with the seq implementation). Am I right with my thoughts? Thanks, fweth

3 3

Padding List with Zeros
by Lorenzo Isella 15 Sep '10

15 Sep '10

Dear All, I still have to find my way with immutable lists and list comprehension. Consider the following lists A=[0,10,20,30,40,50] B=[0,10,50] (i.e. B is a subset of list A; list A is already ordered in increasing order and so is B). C=[2,1,-5] i.e. there is a corresponding element in C for every element in B. Now, I would like to define a new list D having length equal to the length of A. The elements of D in the position of the elements of A in common with B are equal to the corresponding entries in C, whereas the other ones are zero i.e. D=[2,1,0,0,0,-5]. How can I achieve that? The first thought that comes to my mind is to define a list of zeros which I would modify according to my needs, but that is not allowed... Many thanks Lorenzo

8 13

Randomness, lists, and unfoldr
by Alex Rozenshteyn 14 Sep '10

14 Sep '10

I'm trying to build a list where each entry depends on the previous one. Unfoldr seemed like a good idea at the time. Unfortunately, my values are monadic values (specifically RVars, from the random-fu package). Okay, shouldn't be a problem; I just monadic bind and... > -- example code > updateCell :: Bool -> RVar Bool > updateCell False = return False > updateCell True = bernoulli (0.9 :: Double) > sim = sequence $ take 20 $ unfoldr (\x -> Just (x, x >>= updateCell)) (return True) > runRVar sim DevURandom [True,True,True,True,True,False,True,False,True,False,False,False,False,False,False,True,True,False,False,False] That output shouldn't be possible if I'm doing things right... It appears that each cell has an independent history. I'm stumped. Advice on threading monad input in general and random-fu in specific would be appreciated. -- Alex R

6 7

List Sorting and I/O
by Lorenzo Isella 14 Sep '10

14 Sep '10

Dear All, Thanks to the help I got from the list, I was able to (almost) finish a script that performs some data postprocessing (and the code is really amazingly short). Now, there are a few things left. Consider the lists bs = [4,5,3,1,5,2,7,2,8,2,2,3,3,5,6,7] and ms = [2,2,2,2,4,4,4,4,6,6,4,4,4,10,12,14] Now, I would like to sort bs (and that is easy) and then (since there is a 1-1 correspondence between the elements in ms and bs) re-order the elements in ms accordingly i.e. bs would become [1,2,2,2,2,3,3,3,4,5,5,5,6,7,7,8] and ms [2,4,4,6,4,2,4,4,2,2,4,10,12,4,14]. How can I achieve that? Finally, I would like to be able to save the two lists as plain text files (no commas, no brackets). I tried writeFile+Show, but this saves the lists exactly as printed on screen (whereas I simply would like a text file showing a column of numbers when opened by your favorite editor). Many thanks Lorenzo

2 2

Re: how to implement accesor function for given data type
by Brent Yorgey 13 Sep '10

13 Sep '10

On Mon, Sep 13, 2010 at 05:33:12PM +0200, Martin Tomko wrote: > Hi Brent, > thank you for your help. Indeed, I need to be able to distinguish > them in terms of single coordinate, tuple or list - that is crucial > in order to keep the logic. > I am not sure how your second suggestion would help though, because > then I would get a function to return the > CoordinateSet, but then I would need again to somehow extract the > individual vertices out of it for any mathematical processing. And > again, I will be faced by the same problem. just one wrapper further, > am I right? No, you won't still have the same problem. The problem before was that you wanted to write a function which could return values of several different types, which is not possible. (Well, technically, it IS possible, but not in a way that would be helpful to you.) This solution allows you to wrap the options up in a single type. Of course, you will later need to extract vertices out of the Coordinates type for processing -- but that's just fine, you can write the processing function by cases on the Coordinates type. However, you might decide that the intermediate step is not all that helpful and just write the mathematical processing directly by cases on Geometry. It depends on what the mathematical processing looks like, I suppose. > This is what I end up with: > > type Coordinate = (Float, Float) > > data Coordinates = Pt Coordinate | Ls (Coordinate, Coordinate)| Pl > [Coordinate] deriving (Show,Eq) -- this is what you called the > CoordinateSet > > data Geometry = Point FID Coordinates > | LineSegment FID Coordinates > | Polyline FID Coordinates > | Polygon FID Coordinates > deriving (Show,Eq) This looks wrong to me, since this would allow (say) a Point to have a list of coordinates, or a Polygon to have just a single coordinate. I think you want to stick with what you had before. > > Then, indeed, the whole Geometry ADT seems redundant, and could be It doesn't look redundant to me. For example, isn't there a difference between a Polyline and a Polygon (even if they have the same coordinates)? > Let us assume a practical example: I want to find vertices shared by > two geometries, using intersect or elem seems to be the way to go, > depending if either are lists or soem are single points (not sure > this will work on tuples... I would prefer a single solution for > all). > My thinking is that I need a function to get to the Coordinates of a > geometry somehow, and maybe convert the mto a vector, but that sounds > like a dirty trick not worthy of Haskell! Why not: shared :: Geometry -> Geometry -> [Coordinate] shared geo1 geo2 = sharedCoords (getCoords geo1) (getCoords geo2) sharedCoords :: Coordinates -> Coordinates -> [Coordinate] sharedCoords (Pt p1) (Pt p2) = if (p1 == p2) then [p1] else [] sharedCoords (Pt p1) (Ls (x,y)) = ... sharedCoords (Pt p1) (Pl cs) = ... ... and so on. This is what I mean by doing mathematical analysis by cases on Coordinates. -Brent

1 0