September 2009 - Haskell-Cafe

Re: [Haskell-cafe] Haskell for Physicists
by edgar＠ymonad.com 30 Sep '09

30 Sep '09

On Wed, 30/Sep/2009 at 22:27 +0200, Max Rabkin wrote: > I am *not* a physicist, but I imagine many physicists know at least > something of functional analysis, algebra, Lie algebras, etc. > > However, when physicists write programs (this is my inference from the > widespread use of Fortran and the computational assignments given to > undergraduate students) they are almost exclusively numerical: very > often evaluating some integrals or integrating a system of > differential equations. Although Haskell can do these things, it's not > a place where Haskell really shines (compared to symbolic > computation). Well, if you want to write all the code in Haskell, maybe this is true (some parts an imperative code still is the most efficient, but nothing that you can't do in C and use in Haskell via FFI). But in my case, Haskell really shined using as an interface to GSL/Lapack via the wonderful hmatrix lib. > Since I'm not a physicist, I can't give a good example, but think more > of the things Mathematica is good for, rather than Fortran or Matlab. > My impression is that Haskell's advantage over Mathematica is in its > generality: Mathematica is great if it has a builtin function to do > what you want, but it's not a very pleasant programming language. And speed is other advantage! The code that I wrote to solve a problem in bose condensation is dozen times fastest that the Mathematica equivalent, and much more clean and simple to expand or modify. Edgar > HTH, > Max > > On Wed, Sep 30, 2009 at 9:39 PM, Khudyakov Alexey > <alexey.skladnoy(a)gmail.com> wrote: > > В сообщении от Среда 30 сентября 2009 23:29:32 Max Rabkin написал: > >> On Wed, Sep 30, 2009 at 9:24 PM, Alberto G. Corona <agocorona(a)gmail.com> > > wrote: > >> > Haskell: mathematics beyond numerical calculus > >> > >> I'd imagine most physicists know a fair bit of mathematics beyond > >> numerical calculus; what they might not know much about is > >> *computation* beyond numerical calculus. > >> > > Could you elaborate this. As physicist I don't quite get it. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Re: [Haskell-cafe] Haskell for Physicists
by edgar＠ymonad.com 30 Sep '09

30 Sep '09

Good ones! Specially the second, since I will show a real example where I used Haskell to model a boson condensate. Thanks for the suggestions. Edgar On Wed, 30/Sep/2009 at 10:52 -0700, Ted Nyman wrote: > Some ideas of highly variable quality: > > Getting Functional with Physics > Bosons, Fermions, and Monads? Haskell for Physicists > Purer Programming for Physicists > Use Haskell for Physics, and Say 'C'-You-Later > > - ted > > On Wed, Sep 30, 2009 at 10:42 AM, <edgar(a)ymonad.com> wrote: > > > Hi, > > > > I will give a seminar to physicists at USP (Universidade de São Paulo, > > Brazil) university and they asked me for a good title, something that can > > attract physicists. Anyone has some suggestions? (Will be > > a seminar about the use of Haskell to substitute C or Fortran > > in a lot of tasks, and how it can be used in some problems instead of > > Matlab, Mathematica, etc.) > > > > Thanks, > > Edgar > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

1 0

Re: [Haskell-cafe] Haskell for Physicists
by Jack Norton 30 Sep '09

30 Sep '09

Khudyakov Alexey wrote: > В сообщении от Среда 30 сентября 2009 22:25:14 вы написали: > >> Khudyakov Alexey wrote: >> >>> В сообщении от 30 сентября 2009 21:42:57 edgar(a)ymonad.com написал: >>> >>>> Hi, >>>> >>>> I will give a seminar to physicists at USP (Universidade de São Paulo, >>>> Brazil) university and they asked me for a good title, something that >>>> can attract physicists. Anyone has some suggestions? (Will be a seminar >>>> about the use of Haskell to substitute C or Fortran >>>> in a lot of tasks, and how it can be used in some problems instead of >>>> Matlab, Mathematica, etc.) >>>> >>> What area of physics? They all face somewhat different problems from >>> computation. >>> >>> Could you publish your slides from seminar (if any) and even if they are >>> in Spanish (nothing is impossible for man with a dictionary) >>> >> I am also interested in seeing the slides (being a physicist myself). >> Also, that'd be portuguese, not spanish, that would be spoken in >> Brazil. The dictionary comment still applies though :) >> >> > I suppose you aimed for cafe but missed. (: > Yep, sure did. I just hit `reply' assuming haskell-cafe was in the reply-to. I do that more often than not it seems. Going back to the OP, what area of physics, and how on earth are you going to convert years of fortran users to haskell? I mean, in particle physics (were I came from) it seems as though only recently have they moved from fortran to C++ (note: C was skipped). There are things written in python (like Athena) but, well..., they are unreliable crap (I do like python though). In fact, when I was in undergraduate, not 4 years ago, a PhD student was writing his big QCD project in fortran from the ground up. I'm not even familiar enough with fortran to attempt such a thing (I would have used C). Case in point, I think there are some areas of physics that exist as a communal project (i.e. experimental particle physics) and because of this, you are limited to the tools and data used by your peers (Athena, Geant4, etc...). It is really hard to introduce anything new. So I guess my advice would be to avoid Haskell as a 'replacement' for anything to a physicist (including mathematica -- which I never liked myself). They will immediately ignore you. Approach it as a new tool, and focus on what it can do that software-x can't. That was my take on it though, so it may be a bit incorrect and/or biased. -Jack

2 2

Fwd: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
by Alberto G. Corona 30 Sep '09

30 Sep '09

I would say that pure knowledge is pure and functional. but human planning and problem solving is imperative because implies sequencing of operations based on this pure knowledge. haskell express both nicely. 2009/9/30 Andrew Coppin <andrewcoppin(a)btinternet.com> > Peter Verswyvelen wrote: > >> I really doubt people tend to think in either way. It's not even sure our >> thinking can be modeled with computing no? >> > > Well, try this: Go ask a random person how you add up a list of numbers. > Most of them will say wsomething about adding the first two together, adding > the third to that total, and so forth. In other words, the step by step > instructions. Very few of them will answer that the sum of an empty list is > defined to be zero, and the sum of a non-empty list is defined to be the > first number plus the sum of the list tail. > > Then again, few non-programmers will set anything about creating a counter > variable and initialising it to zero either; this is a programming > "artifact". (Humans don't think like this internally, but most programming > languages conceptually require it.) Nobody has much difficulty with this, so > maybe the only problem with Haskell is that everybody learns to program "the > other way" first, before they get to Haskell... > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

Fwd: [Haskell-cafe] I read somewhere that for 90% of a wide class of computing problems, you only need 10% of the source code in Haskell, that you would in an imperative language.
by Alberto G. Corona 30 Sep '09

30 Sep '09

Again, i missed to forward the message to the list: I experince also the drug effect. Evolutionary psychologists would say that, because it was vital for our survival, since the stone age, we appreciate any tool powerful enough to solve many problems while at the same time remain simple. So whenever the utility versus learning.-using-,maintaining costs of a tool is low. then the tool is more appreciated and more pleasure we experiencie by using it. That applies either to a sword, a horse, a car or a programming language. Haskell has an execution strategy and a type system that cares for himself about code consistency and a reasonable optimization, It has only a few keywords, and a intuitive syntax , But combining the security that gives the first two factors and the flexibility of the other two, one can reach high levels of abstraction maintaining a high degree of confidence in the generated code, And such code can be applied to a wider variety of problems. For that matter I think that while other languages can borrow some features of haskell, they will never have the power that can be achieved by having them all. And most of them are deep in the core. 2009/9/30 Peter Verswyvelen <bugfact(a)gmail.com> Yep, LINQ makes C# more enjoyable :-) Scala and haXe also look nice, a bit > of a mix between OCaml/F#, C#/Java and Haskell. > Besides the fact that hacking in Haskell is a great deal of fun, the main > reason I see for learning Haskell: it makes you a better programmer. After > a couple of years of playing with Haskell, I can now solve problems that I > couldn't before. It's of course hard to tell if Haskell is the reason here, > or just experience, but I feel it really is Haskell (actually, functional > programming). Haskell made me see the world in a different way (and if I see > Oleg's and co's code, I still have an infinitely long road ahead. > > The main reason why you should not learn Haskell: it's a bit of a drug; > after you learned Haskell, programming in an "industrial strength" language > suddenly feels like a waste of time, time better spent learning more > Haskell... > > On Wed, Sep 30, 2009 at 10:26 AM, Deniz Dogan <deniz.a.m.dogan(a)gmail.com>wrote: > >> 2009/9/30 Andrew Coppin <andrewcoppin(a)btinternet.com>: >> > (Mr C++ argues that homo sapiens fundamentally think in an imperative >> way, >> > and therefore functional programming in general will never be popular. >> >> Sounds more like Mr C++ fundamentally thinks in an imperative way >> because that's what he is used to. >> >> I recently started working with C# and struggled for way too long with >> for/foreach loops to do things that in Haskell could be expressed >> using only folding, mapping and filtering. When I realised that those >> ideas actually exist in System.Linq I suddenly started liking the >> language a bit more. >> >> txtCommaSeparatedNames.Text.Split(',').Select(x => x.Trim()).Where(x >> => x.Length > 0).Select(x => Convert.ToInt32(x)).ToList(); >> >> Ah, the joy of FP. >> >> -- >> Deniz Dogan >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

1 0

Fwd: [Haskell-cafe] frag game-compiling error
by selahaddin gerdan 30 Sep '09

30 Sep '09

---------- Forwarded message ---------- From: selahaddin gerdan <selahattin.gerdan(a)gmail.com> Date: 2009/9/28 Subject: Re: [Haskell-cafe] frag game-compiling error To: Lyndon Maydwell <maydwell(a)gmail.com> Sorry I'm just learning haskell, so I don't get your suggestion. Could you explain to me what exactly I have to do? According to this<http://cvs.haskell.org/Hugs/pages/libraries/OpenGL/Graphics-Rendering-OpenG…>page GLfloat is just a type synonym for type Float. How come the error message differentiates between them? 2009/9/28 Lyndon Maydwell <maydwell(a)gmail.com> I think this is an opengl version problem. I came across this error in > vacuum-opengl after I had upgraded my opengl. I patched it up using a > "from<numeric type>" call. > > On Mon, Sep 28, 2009 at 8:00 AM, selahaddin gerdan > <selahattin.gerdan(a)gmail.com> wrote: > > Hi there, > > when I try to install frag,I get this error: > > > > .cabal/bin/cabal install frag > > Resolving dependencies... > > Downloading frag-1.1.2... > > Configuring frag-1.1.2... > > Preprocessing executables for frag-1.1.2... > > Building frag-1.1.2... > > [ 1 of 39] Compiling IdentityList ( src/IdentityList.hs, > > dist/build/frag/frag-tmp/ > > IdentityList.o ) > > [ 2 of 39] Compiling Quaternion ( src/Quaternion.hs, > > dist/build/frag/frag-tmp/Quaternion.o ) > > > > src/Quaternion.hs:22:27: > > Couldn't match expected type `GLfloat' > > against inferred type `Float' > > In the expression: (r00 :: GLfloat) > > In the second argument of `newMatrix', namely > > `[(r00 :: GLfloat), r01, r02, r03, ....]' > > In the expression: > > newMatrix ColumnMajor [(r00 :: GLfloat), r01, r02, r03, ....] > > cabal: Error: some packages failed to install: > > frag-1.1.2 failed during the building phase. The exception was: > > exit: ExitFailure 1 > > > > Why? > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > >

6 5

Problem with result-type context restrictions in typeclasses.
by DNM 30 Sep '09

30 Sep '09

N.B. I'm a newbie to Haskell, and this problem is a bit complex, so bear with me. I'm using typeclasses to implement a sort of common interface for all things -- call them things of type 'Cls' -- that can be expected to implement a set of functions -- an 'interface' in OOP-speak. (Yes, yes, I'm aware that typeclasses are subtly different and far superior, but my Haskell-ese is still a bit rudimentary.) Essentially, I want to have a typeclass that expects its instances to have an accessor function that results in something that is an instance of another typeclass whose instances can perform some operation. The ghc type-checker doesn't seem to like my code, though, and I can't seem to figure out why. To make it concrete, I've typed up some dummy typeclasses and a dummy function that uses their instances to illustrate what I mean, as well as the form of the ghc(i) error. ------------- BEGIN CODE ------------------ class Cls c where foo :: (Bar b) => c -> b class Bar b where toNum :: b -> Int -- | One implementation of Cls data D = D {fu :: FU} data FU = FU {num :: Int} instance Cls D where foo = fu instance Bar FU where toNum f = (num f) + 47 -- | Another implementation of Cls data E = E {fi :: FI} data FI = FI {nuum :: Int} instance Cls E where foo = fi instance Bar FI where toNum f = (nuum f) + 100 -- | Yet another (this one re-uses FI) data F = F {fii :: FI} instance Cls F where foo = fii -- | And one last one, just to stress that -- I really need to implement multiple -- instances of Cls. data G = G {fuu :: FU} instance Cls G where foo = fuu -- | Good. Now, the function 'useThisStuff' need -- not know anything about it's payload -- other than that it its args are Cls's -- (hence they are foo'able things that -- can be used to construct an Int answer). useThisStuff :: (Cls x, Cls y) => x -> y -> Int useThisStuff x y = (toNum $ foo x) + (toNum $ foo y) ------------- END CODE -------------------- When I type this up in a file and try to load it in ghci, I get the following error message(s): ------------- BEGIN ERROR MSG ---------- Prelude> :load Typeclasses.hs [1 of 1] Compiling Typeclasses ( Typeclasses.hs, interpreted ) Typeclasses.hs:14:10: Couldn't match expected type `b' against inferred type `FU' `b' is a rigid type variable bound by the type signature for `foo' at Typeclasses.hs:4:16 Expected type: D -> b Inferred type: D -> FU In the expression: fu In the definition of `foo': foo = fu Typeclasses.hs:23:10: Couldn't match expected type `b' against inferred type `FI' `b' is a rigid type variable bound by the type signature for `foo' at Typeclasses.hs:4:16 Expected type: E -> b Inferred type: E -> FI In the expression: fi In the definition of `foo': foo = fi Typeclasses.hs:31:10: Couldn't match expected type `b' against inferred type `FI' `b' is a rigid type variable bound by the type signature for `foo' at Typeclasses.hs:4:16 Expected type: F -> b Inferred type: F -> FI In the expression: fii In the definition of `foo': foo = fii Typeclasses.hs:39:10: Couldn't match expected type `b' against inferred type `FU' `b' is a rigid type variable bound by the type signature for `foo' at Typeclasses.hs:4:16 Expected type: G -> b Inferred type: G -> FU In the expression: fuu In the definition of `foo': foo = fuu Failed, modules loaded: none. ------------- END ERROR MSG ------------ It seems that ghc doesn't like the fact that I am saying 'foo' must return a class 'b' of typeclass 'Bar', while providing a function that returns a concrete data instance of 'Bar' (viz., FU or FI) later on when I implement 'foo' in each type classes. Repeated for convenience: class Cls c where foo :: (Bar b) => c -> b ... -- (e.g.) data G = G {fuu :: FU} instance Cls G where foo = fuu Does anyone have any clue as to what I'm doing wrong (language extensions that I may need, etc.)? Is is because I'm using context restrictions on the *result* type of a typeclass method? I've written other typeclasses with methods that say, essentially: class A a where blah :: (MonadPlus m) => a -> a -> m a with no issues. The restriction there is not on the return type a, but rather on some monadic 'wrapper' around it. This may be why that code works. Please advise. Any help is greatly appreciated. --D.N. (Dennis)

5 6

Any working example of using genericserialize?
by Dimitry Golubovsky 30 Sep '09

30 Sep '09

Hi, I am trying to use the genericserialize package (http://hackage.haskell.org/package/genericserialize) but cannot get things working. While buildList (sexpSerialize [1, 2, 3]) yields "(1 2 3)" as it might be expected, I cannot deserialize it back: *Main> (withList sexpDeserialize $ buildList (sexpSerialize [1, 2, 3])) :: Maybe [Integer] Nothing or *Main> (withList sexpDeserialize $ buildList (sexpSerialize [1, 2, 3])) :: Maybe [Int] Nothing while I would expect at least one of these cases result in Just [1, 2, 3] What am I missing? Thanks. -- Dimitry Golubovsky Anywhere on the Web

2 1

i am missing something really trivial with parsec
by Anatoly Yakovenko 30 Sep '09

30 Sep '09

number = do { num <- natural ; return $ num } main = do txt <- hGetContents stdin print $ parse number "stdin" txt why doesn't that work?

3 2

Type synonyms vs standard types
by Olex P 30 Sep '09

30 Sep '09

Hi everyone, Dumb question about declaring a function and type synonyms. There are to different declarations of the same function: attrNames :: String -> AttrDict -> [String] attrNames :: AttrClass -> AttrDict -> AttrNames First gives you the idea about exact types it expects (except AttrDict for which user has to take a look into the docs or sources) while the second one gives you the idea about meaning of parameters. Both reasons make sense. The question is when which one should be used? I'm using type synonyms everywhere and possibly without too much reasons... Maybe I should stop doing it? :) Cheers, Oleksandr.

4 6