February 2015 - Beginners

pattern matching on strings ?
by Roelof Wobben 20 Feb '15

20 Feb '15

Hello, Im try to the solve the exercise which does the following : "E 2 562 help he and convert it into (Error 2) 562 "help help First I thought to split the string on the " " but according to google Haskell do not have a split function. Can I use pattern matching on some way ? Roelof

6 6

Re: [Haskell-beginners] tower hanoi problem
by Doug McIlroy 20 Feb '15

20 Feb '15

On 2/19/15 4:47 AM, Joel Neely wrote: > Incidentally, I also find it interesting to see the subtle effects > that our terminology has on the way we approach problems. Thinking of > a list as "it may be empty or not" takes my thoughts in a different > direction than if I think "it may have a head or not". A telling aphorism. It will stick with me for a long time. Regarding the problem that sparked this discussion, Hanoi: if you think first about the base case, it's likely to be this: to transfer a oone-disc pile from A to B using C as an intermediate, move A to B. If you think first about the recursive step, you'll likely come up with a different base case: to transfer zero discs, do nothing. With this insight, you've generalized your original understanding of the problem. Doug

1 0

function to read file and return list of contents not compiling
by Geoffrey Bays 19 Feb '15

19 Feb '15

Haskellers: I want to write a function that takes a class name and reads from a file and then returns the list of String of the file lines. I have experimented with various return types, but GHC does not like any of them. Here is my function: readData :: String -> IO String -- what type here?? readData classNameP = do let fileName = classNameP ++ ".txt" contents <- readFile fileName lines contents Not to complain, but this would not be difficult in any other language I have tried, so I could use some explanation. I suspect it has to do with understanding the IO Monad. Many Thanks Geoffrey

2 3

hanoi 4 problem
by Roelof Wobben 19 Feb '15

19 Feb '15

Hello, I try now to make the optional exercise hanoi with 4 pegs, So I did on paper this : start temp1 temp2 end 3 2 1 first move : start -> temp2 start temp1 temp2 end 2 3 1 second move : start -> temp1 start temp1 temp2 end 1 2 3 now I tried to make this piece in code So I did : hanoi4 1 start _ _ end = "move 1 disk from " ++ [start] ++ " to " ++ [end] ++ ".\n" hanoi4 n start temp1 temp2 end = hanoi4 (n-1) start end temp1 temp2 ++ hanoi4 1 start end temp1 temp2 ++ hanoi4 (n-1) start temp1 end temp2 because on the first step start must be start and end must be temp1 and on the second step start must be start and end must be temp2 but when I run in I see this output : move 1 disk from a to b. move 1 disk from a to b. move 1 disk from a to b. move 1 disk from a to c. move 1 disk from a to d. move 1 disk from a to d. move 1 disk from a to d. Can anyone explain or let me see where my thinking took the wrong turn ? Roelof

2 2

tower hanoi problem
by Roelof Wobben 19 Feb '15

19 Feb '15

8 55

enumaratioin question
by Roelof Wobben 19 Feb '15

19 Feb '15

3 6

Package access problem
by Gregory Guthrie 19 Feb '15

19 Feb '15

I installed diagrams, and it seems to be there, but GHCi doesn't find it. I tried adding the local sandbox to the command line (-package-db), but still no luck Any suggestions? C:\Users\guthrie> C:\Users\guthrie>cabal install diagrams Resolving dependencies... All the requested packages are already installed: diagrams-1.2 Use --reinstall if you want to reinstall anyway. I find it in: C:\Users\guthrie\.cabal-sandbox\i386-windows-ghc-7.6.3-packages.conf.d (diagrams-1.2, diagrams-contrib, -core, -lib, -svg) But running: "cabal repl" or using the GHC(i) flag "-package-db=..." fail to find it: C:\Users\guthrie>cabal repl GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :m + Diagrams <no location info>: Could not find module `Diagrams' It is not a module in the current program, or in any known package. Prelude> :m + Diagrams.Prelude <no location info>: Could not find module `Diagrams.Prelude' It is not a module in the current program, or in any known package. Prelude> ----------------------------------------------------------

4 3

Haskell implementation of longest path algorithm
by Jeremy 19 Feb '15

19 Feb '15

Compared to the Nim code [https://github.com/logicchains/LPATHBench/blob/master/nim.nim] for a longest path algorithm, Haskell [https://github.com/logicchains/LPATHBench/blob/master/hs.hs] looks horrendously verbose and ugly, even if you ignore the pragmas and imports. Is this idiomatic Haskell style? Could it be clearer, but has to be written that way for performance - although it still takes 3.7x as long as the Nim version [https://github.com/logicchains/LPATHBench/blob/master/writeup.md]?

1 0

Re: [Haskell-beginners] tower hanoi problem
by Roelof Wobben 18 Feb '15

18 Feb '15

Oke, Im thinking of this way hanoi 3 source between end hanoi 1 source _ end = [ (source, end)] hanoi n source between end = hanoi (n-1) xxxx print move somehow. Roelof Dudley Brooks schreef op 18-2-2015 om 17:19: > There are three *locations*. But there is only one *thing* -- only > *one at a time*, that is, namely whichever one you are moving on any > given move, be it a disc or an entire stack. > > On 2/17/15 11:10 PM, Roelof Wobben wrote: >> That part I understand already. >> >> The only thing I do not see is what the base case in this exercise is >> because you are working with 3 things instead of 1 for example a list. >> >> As a example reversing a list recursive >> >> the base case is the not reversed list is empty. >> >> >> Roelof >> >> >> >> Dudley Brooks schreef op 18-2-2015 om 8:04: >>> On 2/17/15 10:56 PM, Dudley Brooks wrote: >>>> On 2/16/15 7:06 PM, Doug McIlroy wrote: >>>>>> My way of working is one problem at the time. >>>>>> So first solve the itterate one and after that I gonna try to >>>>>> solve the >>>>>> recursion one. >>>>>> Otherwise I get confused. >>>>> This is the crux of the matter. You must strive to think those >>>>> thoughts >>>>> in the opposite order. Then you won't get confused. >>>>> >>>>> Recursion takes a grand simplifying view: "Are there smaller >>>>> problems of >>>>> the same kind, from the solution(s) of which we could build a >>>>> solution of >>>>> the problem at hand?" If so, let's just believe we have a solver >>>>> for the >>>>> smaller problems and build on them. This is the recursive step. >>>>> >>>>> Of course this can't be done when you are faced with the smallest >>>>> possible problem. Then you have to tell directly how to solve >>>>> it. This is the base case. >>>>> >>>>> [In Hanoi, the base case might be taken as how to move a pile >>>>> of one disc to another post. Even more simply, it might be how >>>>> to move a pile of zero discs--perhaps a curious idea, but no more >>>>> curious than the idea of 0 as a counting number.] >>>>> >>>>> A trivial example: how to copy a list (x:xs) of arbitrary length. >>>>> We could do that if we knew how to copy the smaller list tail, xs. >>>>> All we have to do is tack x onto the head of the copy. Lo, the recipe >>>>> copy (x:xs) = x : copy xs >>>>> Final detail: when the list has no elements, there is no smaller >>>>> list to copy. We need another rule for this base case. A copy >>>>> of an empty list is empty: >>>>> copy [] = [] >>>>> >>>>> With those two rules, we're done. No iterative reasoning about >>>>> copying all the elements of the list. We can see that afterward, >>>>> but that is not how we got to the solution. >>>>> >>>>> [It has been suggested that you can understand recursion thus >>>>> > Do the first step. Then (to put it very dramatically) >>>>> > do *everything else* in *a single step*! >>>>> This point of view works for copy, and more generally for >>>>> "tail recursion", which is trivially transformable to iteration. >>>>> It doesn't work for Hanoi, which involves a fancier recursion >>>>> pattern. The "smaller problem(s)" formulation does work.] >>>> >>>> I simplified it (or over-dramatized it) to the point of >>>> not-quite-correctness. I was trying to dramatize the point of how >>>> surprising the idea of recursion is, when you first encounter it >>>> (because I suspected that the OP had not yet "grokked" the elegance >>>> of recursion) -- and remembering my own Aha! moment at recursive >>>> definitions and proofs by induction in high school algebra, back >>>> when the only "high-level" programming language was assembly. I >>>> see that I gave the mistaken impression that that's the *only* kind >>>> of recursive structure. What I should have said, less dramatically, is >>>> >>>> Do the base case(s) >>>> Then do the recursion -- whatever steps that might involve, >>>> including possibly several recursive steps and possibly even >>>> several single steps, interweaved in various possible orders. >>>> >>>> You can't *start* with the recursion, or you'll get either an >>>> infinite loop or an error. >>>> >>>> I wouldn't quite call the conversion of tail-recursion to iteration >>>> trivial, exactly ... you still have to *do* it, after all! And >>>> when I did CS in school (a long time ago), the equivalence had only >>>> fairly recently been recognized. (By computer language designers, >>>> anyway. Maybe lambda-calculus mathematicians knew it long before >>>> that.) Certainly the idea that compilers could do it automatically >>>> was pretty new. If it were *completely* trivial, it would have >>>> been recognized long before! ;^) >>>> >>>> If you're younger you probably grew up when this idea was already >>>> commonplace. Yesterday's brilliant insight is today's trivia! >>> >>> BTW, since, as you and several others point out, the recursive >>> solution of Towers of Hanoi does *not* involve tail recursion, >>> that's why it's all the more surprising that there actually is a >>> very simple iterative solution, almost as simple to state as the >>> recursive solution, and certainly easier to understand and follow by >>> a novice or non-programmer, who doesn't think recursively. >>>> >>>>> In many harder problems a surefire way to get confused is to >>>>> try to think about the sequence of elementary steps in the final >>>>> solution. Hanoi is a good case in point. >>>>> >>>>> Eventually you will come to see recursion as a way to confidently >>>>> obtain a solution, even though the progress of the computation is >>>>> too complicated to visualize. It is not just a succinct way to >>>>> express iteration! >>>>> >>>>> Doug McIlroy >>>>> _______________________________________________ >>>>> Beginners mailing list >>>>> Beginners(a)haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>>> >>> >>> _______________________________________________ >>> Beginners mailing list >>> Beginners(a)haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners >>> >> > >

3 9

Re: [Haskell-beginners] Beginners Digest, Vol 80, Issue 39
by Gregory Guthrie 18 Feb '15

18 Feb '15

Thank you for the clarification; I should not have included that example - but the issue is with the other names that should work as in the same example below; "import Diagrams.Prelude", import Diagrams.Backend.SVG.CmdLine, etc. ------------------------------------------- > I installed diagrams, and it seems to be there, but GHCi doesn't find it. I tried adding the > local sandbox to the command line (-package-db), but still no luck Any suggestions? > > C:\Users\guthrie> > C:\Users\guthrie>cabal install diagrams > Resolving dependencies... > All the requested packages are already installed: > diagrams-1.2 > Use --reinstall if you want to reinstall anyway. > > I find it in: > C:\Users\guthrie\.cabal-sandbox\i386-windows-ghc-7.6.3-packages.conf.d (and C:\Users\guthrie\.cabal-sandbox\i386-windows-ghc-7.6.3 ) > (diagrams-1.2, diagrams-contrib, -core, -lib, -svg) > > But running: "cabal repl" or using the GHC(i) flag "-package-db=...(as above)..." > fail to find it: > > C:\Users\guthrie>cabal repl > GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Prelude> :m + Diagrams.Prelude > > <no location info>: > Could not find module `Diagrams.Prelude' > It is not a module in the current program, or in any known package. > Prelude> > ----------------------------------------------------------

2 1