- Haskell-Cafe - Haskell.org

RE: Ann: HAllInOne bug fix release
by Hal Daume 31 Jul '03

31 Jul '03

(haskell-cafe now) Interesting. I've stripped them and they are exactly the same size. diff says they differ though. pre-stripping, the normal nhc (non ai1) is marginally larger (6.8m versus 7.0m). I'll try to measure memory usage if someone tells me how :) - Hal -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume > -----Original Message----- > From: haskell-admin(a)haskell.org > [mailto:haskell-admin@haskell.org] On Behalf Of John Meacham > Sent: Wednesday, July 30, 2003 5:22 PM > To: The Haskell Mailing List > Subject: Re: Ann: HAllInOne bug fix release > > > Another useful thing would be the striped binary sizes of the two > versions. I am curious how much AllInOneing affects the resultant > binary. Memory usage would also be interesting. > John > > On Wed, Jul 30, 2003 at 04:22:58PM -0700, Hal Daume wrote: > > Ah, apparently it is not (at least not the Cygwin version). > > > > I recompiled NHC with GHC -O2, both the separate > compilation version and > > the all-in-over version. Averaged over five runs, we see that the > > separate compilation version is actually *faster* than the > ai1 version: > > > > standard nhc compiled with ghc: > > > > real 0m27.167s > > user 0m9.991s > > sys 0m1.304s > > > > nhc all-in-one: > > > > real 0m31.411s > > user 0m10.007s > > sys 0m1.299s > > > > > > > > i am completely unable to explain this. someone want to > hazard a guess? > > > > - hal, who is a bit disappointed now :( > > > > -- > > Hal Daume III | hdaume(a)isi.edu > > "Arrest this man, he talks in maths." | > www.isi.edu/~hdaume > > > > > > > -----Original Message----- > > > From: haskell-admin(a)haskell.org > > > [mailto:haskell-admin@haskell.org] On Behalf Of Wolfgang Jeltsch > > > Sent: Wednesday, July 30, 2003 2:59 PM > > > To: The Haskell Mailing List > > > Subject: Re: Ann: HAllInOne bug fix release > > > > > > > > > On Wednesday, 2003-07-30, 23:36, CEST, Hal Daume III wrote: > > > > [...] > > > > > > > A few people have asked me for speed-up results from > > > All-In-One-ifying code, > > > > so here's a good one. We take two versions of NHC. One is > > > the original > > > > binary distribution and the other is the All-In-One-ified > > > version, compiled > > > > by GHC. > > > > > > Hi, > > > > > > is the original binary distribution compiled with GHC? If > > > not, the speed-up > > > may also be the result of using a different compiler (i.e., GHC). > > > > > > > [...] > > > > > > Wolfgang > > > > > > _______________________________________________ > > > Haskell mailing list > > > Haskell(a)haskell.org > > > http://www.haskell.org/mailman/listinfo/haskell > > > > > -- > > Haskell mailing list > > Haskell(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell > > > > -- > -------------------------------------------------------------- > ------------- > John Meacham - California Institute of Technology, Alum. - > john(a)foo.net > -------------------------------------------------------------- > ------------- > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

1 0

RE: Ann: HAllInOne bug fix release
by Hal Daume 31 Jul '03

31 Jul '03

(moved to haskell cafe -- hopefully the other threads will follow) > >I don't know why the all in one version might go slower though > > Virtual memory thrashing? (Hal did say something about > needing lots of RAM.) only to compile. i haven't measured, but the resulting executable shouldn't require any more memory. it only hits about 400mbs max, though, which won't swap on my machine. - hal

1 0

Re: Ann: HAllInOne bug fix release
by Malcolm Wallace 31 Jul '03

31 Jul '03

> Normal: > real 3m14.295s > user 3m9.879s > sys 0m2.143s > > All-In-One: > real 1m11.380s > user 0m10.102s > sys 0m1.711s > Something very odd is going on. GHC does not generate programs than run > 3x faster between GHC versions. This comparison is actually between an nhc98-built program (the first one) and a ghc-built program (the second one), showing that (in this specific case) nhc98 is generating code that is three times slower than that generated by ghc. In my experience, a speed difference of between 2x and 5x of the (unoptimised) generated code between the two compilers is fairly typical. The really odd thing is in the second set of figures. Unless there has been a cut-n-paste mistake, the user+system times do not add up even close to the wall-clock time, suggesting a much greater difference of 18x, which would start to worry me a little if it were true. However, Hal posted an updated set of figures comparing a program separately compiled with ghc to all-in-one compiled with ghc, and these figures seem to have a similar same user+system /= real discrepancy: > separately compiled with ghc: > real 0m27.167s > user 0m9.991s > sys 0m1.304s > all-in-one compiled with ghc: > real 0m31.411s > user 0m10.007s > sys 0m1.299s Is this some kind of known Cygwin timing problem? Do ghc executables fiddle with the internal timers at runtime? :-) Regards, Malcolm

1 0

CSV parser, quotes?
by Shawn P. Garbett 31 Jul '03

31 Jul '03

In attempting to improve the CSV parser based on comments, I have the following code that's attached. I'm having a heck of a time getting the double quotes = an escaped quote thing to work. There is some commented out code which was my last attempt. As it stands the code works, minus the escaped quotes. Remove the comments and it just hangs. module CSV (contents, csv) where import Parsec ---------------------------------------------------------------------- -- CSV Module ---------------------------------------------------------------------- -- Useful common parsers comma :: Parser Char comma = char ',' quote :: Parser Char quote = char '\"' -- How to handle these buggers.... --esc_quote :: Parser Char --esc_quote = do {char '\"'; char '\"';} --text :: Parser String --text = do {esc_quote; t<-text; return ('\"':t)} -- <|> do {c <- noneOf "\""; t<-text; return (c:t) } -- <|> return "" -- A cell can be a quoted value, a number or empty -- Quotes can be embedded by using double quotes "" cell :: Parser String cell = between quote quote (many (noneOf "\"")) -- quoted values --cell = between quote quote text -- quoted values <|> many1 (noneOf "\",\n") -- unquoted values <|> return "" -- give up, Empty cell -- Group of cells with a newline cells :: Parser [String] cells = do c <- sepBy cell comma newline return c -- Comma Separated Values, set of rows followed by eof csv :: Parser [[String]] csv = manyTill cells eof -- Useful For extracting comma delimited values of a cell contents :: Parser [String] contents = sepBy1 (many (noneOf ",")) comma

3 2

RE: Type design question
by Hal Daume 31 Jul '03

31 Jul '03

Hi Konrad, > I am a Haskell newbie working on my first serious test case, > and I would like > some feedback from the experts to make sure I am not doing > anything stupid > ;-) Well, I may not exactly qualify, but I can give you a few suggestions, nonetheless... > data Floating a => Vector a = Vector !a !a !a > deriving (Eq, Show) Here. Do not use 'data C x =>'. It's essentially a useless part of the language that really should have gone away. What you want is just: | data Vector a = Vector !a !a !a deriving (Eq, Show) The Floating constraint can come in on the functions. (I say this feature is useless because it only does one thing: disallows you to construct Vectors whose elements aren't instances of Floating. However, the useful thing that it might do -- namely, allow you to *use* the fact that the elements are instances of Floating -- it doesn't.) > I would like to keep the numerical representation as general > as possible, in > particular to postpone decisions about precision (Float, > Double, eventually > arbitrary precision arithmetic) as much as possible. > Therefore the "Floating > a" constraint. Which leads to my first question: doing it the > way I did, I > find myself having to add a "Floating a" constraint to almost > every function > specification with a vector argument. I would prefer to > specify once and for > all that vector elements need to be "Floating", everywhere. > Is there a way of > doing that? Not really. > -- Periodic universe > data Floating a => OrthorhombicUniverse a = OrthorhombicUniverse a a a Again, get rid of the 'Floating a =>' part. > instance Floating a => Universe (OrthorhombicUniverse a) where > distanceVector (OrthorhombicUniverse a b c) > (Vector x1 y1 z1) (Vector x2 y2 z2) > = Vector (fmod (x2-x1) a) (fmod (y2-y1) b) (fmod (z2-z1) c) > where fmod x y = x - y*truncate (x/y) There are actually two problems. First, you want to write fmod as: | fmod x y = x - y * fromInteger (truncate (x/y)) otherwise the type is wrong. Secondly, since you're using truncate, you need to be in RealFrac, not in Floating. Changing the signature to: | instance RealFrac a => ... fixes this problem. However, once we fix this, we can see the real problem. Your Universe class has a method, distanceVector, of type: | distanceVector :: Universe u, Floating a => u -> Vector a -> Vector a -> Vector a And here's the problem. When 'u' is 'OrthorhombicUniverse x', it doesn't know that this 'x' is supposed to be the same as the 'a'. One way to fix this is to parameterize the Universe data type on the element, something like: class Universe u where distanceVector :: (RealFrac a, Floating a) => u a -> (Vector a) -> (Vector a) -> (Vector a) distance :: (RealFrac a, Floating a) => u a -> (Vector a) -> (Vector a) -> a distance u v1 v2 = norm (distanceVector u v1 v2) -- Infinite universe data InfiniteUniverse a = InfiniteUniverse instance Universe InfiniteUniverse where distanceVector u v1 v2 = v2 <-> v1 -- Periodic universe data OrthorhombicUniverse a = OrthorhombicUniverse a a a instance Universe OrthorhombicUniverse where distanceVector (OrthorhombicUniverse a b c) (Vector x1 y1 z1) (Vector x2 y2 z2) = Vector (fmod (x2-x1) a) (fmod (y2-y1) b) (fmod (z2-z1) c) where fmod x y = x - y*fromInteger (truncate (x/y)) This is beginning to get a little ugly, but I think that's largely because you're using type classes in too much of an OO style (this is what a lot of my first programs looked like and I think for reasons similar to this, I moved away from that). However, not knowing more about the domain of discourse, I don't know what to suggest. Perhaps using the module system would serve you better. Instead of having a universe class, simply put each universe in a separate module and provide the same functions in each. Then you just import them selectively, or qualified. HTH. - Hal

15 24

RE: Useful list output function
by Kevin S. Millikin 30 Jul '03

30 Jul '03

On Wednesday, July 30, 2003 1:52 PM, Shawn P. Garbett [SMTP:Shawn@Garbett.org] wrote: > > output :: (a -> IO b) -> [a] -> IO () > output f = (foldr (>>) (return ())).(map f) Study the Prelude :) > output :: (a -> IO b) -> [a] -> IO () > output = mapM_

1 0

Useful list output function
by Shawn P. Garbett 30 Jul '03

30 Jul '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've got a little function which I derived from Bird's book "Intro to Functional Programming using Haskell". Basically I had several instances of lists that needed outputing with all kinds of text decoration. This function was used repeatedly throughout the code, by removing all the cut and paste instances, this was the common function: output :: (a -> IO b) -> [a] -> IO () output f = (foldr (>>) (return ())).(map f) So given a function that transforms a value of type 'a' into an output of 'IO' and a list of 'a', all IO is performed across the list. Example usage: output f [1,2,3] where f a = putStr ("List contains "++(show a)++"\n")) - -- List contains 1 List contains 2 List contains 3 Probably not very exciting for the old hats at Haskell, but pretty handy to have around at my level of expertise. Shawn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iEYEARECAAYFAj8oIdAACgkQDtpPjAQxZ6AC0ACaA8boOZc8Hjmp9rTAyZ00lPLX QwkAniPsBPHUvBfUcsZlU6TvF1pzkTox =3aEG -----END PGP SIGNATURE-----

1 0

RE: Parsing CSV files
by Simon Peyton-Jones 30 Jul '03

30 Jul '03

| > Hey, I wrote a CSV parser too. seeing as how this seems like a common | > thing (having 3 independent implementations at least), perhaps it | > belongs in libraries somewhere? some area dedicated to useful little | > grammers would be handy. csv, c header files, .x (rpcgen), various | > preference file formats, etc... | | What haskell needs is something along the lines of CPAN. Contributed modules | of various utility. Not part of the base libraries, but never-the-less useful | and maybe needed for your project. There's a lot of activity on this front on the libraries mailing list (libraries(a)haskell.org) http://haskell.org/hawiki/LibraryInfrastructure Simon

1 0

RE: functional graph
by Hal Daume 30 Jul '03

30 Jul '03

> But it looks the Graph class works on types a and b > where a is the Node type where b is the Edge type, or > just the other way around :), I don't have the code > right now. Yes, 'Graph n e' is a graph whose nodes are labelled with elements of type n and whose edges are labelled with elements of type e. > The above rules out my way of representing the data, > or doesn't it (i.e. is there some fancy, magical way > of doing this) ? Yes. (I.e., it rules it out.) > The second intuitive solution is to take a datatype > like > data GraphNode|Teacher etc > |Subject etc > |Student etc > > Should this be the way to do it? Yes. > And then yet another question: I need some kind of way > to remember, which possibilities I already had. > > In example in my C++ program I used a couple of > array's with in each array pointers to the > StudentObjects, TeacherObjects. You could use the same here, or use a FiniteMap. If i'm understanding you correctly you miss the fact that there's no way to look up a node given it's label. This is because the graph module doesn't assume that node labels are unique (otherwise it wouldn't need to generate the Node labels itself). I generally bundle a 'Graph n e' together with a 'FiniteMap n Node' so that I can look up Node identifiers based on node labels. > But then I yet have another problem. How can I > guarantee, to do a complete path traversal, each time > in exactly the same way? I don't understand what you mean. In your case, what is a "complete path traversal." Regardless, if you have the same graph and the same functions for traversing it, since Haskell is referentially transparent you should also "traverse it in the same way..." - Hal

2 1

Parsing CSV files
by Shawn P. Garbett 29 Jul '03

29 Jul '03

I did a small search for parsing a comma seperated file in Haskell and didn't find anything-- so I put together some code to do this. It doesn't handle whitespace very well, this would be a nice addition if someone has an idea out there. Also the rows method, I had trouble just using two do loops without brackets, I couldn't prevent it from being ambiguous. Anyway here's the code: ------------------------- import Parsec import System.IO -- Code to parse a comma seperated file content :: Parser String content = many1 (noneOf "\"") cell :: Parser String cell = do char '\"' w <- content; char '\"' <?> "end of cell" return w; <|> return "" -- Empty cell separator :: Parser () separator = skipMany1 (char ',') cells :: Parser [String] cells = sepBy1 cell separator contents :: Parser [String] contents = sepBy1 content separator; rows :: Parser [[String]] rows = do c <- cells newline do { cs <- rows; return (c:cs); } <|> return [c] csv :: Parser [[String]] csv = do r <- rows eof return r -- Main routine main :: IO () main = do result <- parseFromFile csv "simple.txt" case (result) of Left err -> print err Right sb -> print sb ------------------- Shawn Garbett

6 7