...

- how could I program something like this in Haskell: .. generate random population

Since Haskell is a "pure" language, after you attribute a value to a variable they are glued together forever. So, the language itself can't have such a thing as a random number. (Here, someone with technical knowledge will probably correct me, but you get the poing.) Dealing with this (and other "outside world" stuff) requires learning how to deal with a special type construct called "Monad". It's the major step you will have to as a Haskell begginer. It's, though, extremely interesting, and extremely powerfull after you understand it. I don't think you need that deep of an understanding of monads in order to write random code. You need a basic understanding of "monads as computations", and you need to know how to use do notation, which should feel very much like programming in an imperative language. On the other hand, the rest of the algorithm Luis mentioned is *very* natural in Haskell once you learn how to deal with lists.

...

- Although I always liked math, I no longer have the knowledge I used to have several years ago. Is this important to help program in this funcional language?

No. But if you like math, you're probably going to find links to really interesting math while you learn. I Definitely agree. Being a math student, one of the things I like about Haskell is how it's a "down to earth" example of some very high level concepts showing up-- without necessarily needing to learn all the math

I'm certainly not an expert on Haskell, and my studies over the last year have prevented me from really working in Haskell (or any language) much, but... Maurí­cio CA wrote: that's there. (I spend more time learning the math than the Haskell, but that's a result of my biases, not need.) Now, your other (related) questions: - Is Haskell suitable to process data like this in a fast way (aproximate to C++?) - In order for Haskell to be fast, coding is done in a 'natural' way or with use of special hidden details of the language? Idiomatic Haskell won't be as fast as idiomatic C++, but it will blow Python away. Since I assume you'll be working with large data sets, lazy evaluation may actually make your life much easier. If you really are pushing for lightening fast code, you can do some Don Stewart style hacking, or you can link to C using the foreign function interface. I have no experience with either, but I've heard nothing but the best about Haskell/C interaction. Cheers, Cory

WARNING: THIS IS A VERY LONG REPLY Luis, If you are in a hurry skip to the point where I give advices ;-) ----------------------------------------SKIP IF YOU LIKE TO---------------------------------------------------- I'll ask some more questions!! :-P - Nothing beats Assembly in speed. Why isn't everyone programming in Assembly?? - Python gives me the flexibility for fast prototyping, because it easily connects to C and Java libraries Why isn't every enterprise service bus (ESB) implementation written in Python?? - Ruby has Rails!! One of most successful MVC frameworks ever. Why isn't every system written in Ruby on Rails? Basically, what I am trying to say is that even though Haskell is not blazing fast, it can be made fast enough for you, given you use the right algorithms and optimizations. For this to happen, you must first understand, the functional paradigm, the language and how the compiler optimizes your code. For the rest of your questions: - Is Haskell able to read (also write to a point) data from databases in a fast and reliable way? (MySql or PostgreSQL) Yes, there is a lot of ways. Look at Hackage (HackageDB)http://hackage.haskell.org/packages/hackage.htmlfor database related packages - how could I program something like this in Haskell: .. generate random population .. for each one of the population: .. for time period 1 to ten million: .. evaluate method 1, 2, 3, 4, 5, 6, .... ..evaluate fitness of each one .. generate new population based on results of previous generation It seems relatively intuitive for me to program this in an imperative language. But what about in Haskell? It looks rather imperative to me, either. You can implement imperative things on the IO and State monads, but I would really suggest you rethink the algorithm. - Is Haskell suitable to process data like this in a fast way (aproximate to C++?) How fast, again, depends on the algorithm. Haskell programs look like a collection of mathematical functions. One could write a program like a composition of functions: main= count . words . readfile and then define functions individually... - In order for Haskell to be fast, coding is done in a 'natural' way or with use of special hidden details of the language? The natural way makes you code right, but you have to think every step you do, since a badly organized recursion, or the excess of lazyness can make your program hog on memory and/or go dead slow. - Although I always liked math, I no longer have the knowledge I used to have several years ago. Is this important to help program in this funcional language? The math needed in your first steps is not hard. After you started learning Haskell you will most certainly step on Monads. These might require some abstract algebra, if you want to understand what's behind the curtains. Refrain yourself from trying to understand them using math and take a look on Philip Wadler's "Monads for functional programming"http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf - Are there graphical packages available to plot results or is it easy to connect it to a Python (or C) library? Hackage is the way to go. - Is code easily reusable in different future projects? Since it has no objects... how can it be done? Like all other languages, it all depends on YOU. Haskell has no objects, but it has polymorphic functions, which are just as powerful. It also has type classes, which are almost like C++ object classes, but completely different. Type classes can restrict or increase polymorphism, depending on how you use them. There are also MANY extensions implemented on GHC that expand the type system to its limit. ---------------------------------------- END OF SKIP BLOCK---------------------------------------------------- Is Haskell for you? I can't answer, but I can give some advice: 1) If you are in a hurry, go for what you know (C++, Java, Python, Assembly...) 2) If you really want to dig in, dig in. Learning Haskell is a wonderful experience and can dramatically change your way of programming. Think of a mind altering experience!!! 3) Even though it is hard to write great programs at first, in the end it is very rewarding. As your programming style improves, you'll see how elegant algorithms are implemented in functional programming. I still consider myself a beginner, but I can assure you Haskell is a great language for functional programming. Best regards, Rafael Gustavo da Cunha Pereira Pinto

On 6 Nov 2009, at 17:19, Shawn Willden wrote:

Based on the little bit of stuff I've done, I think I'd characterize it this way: C++ will be maybe twice as fast as Haskell. Maybe a little more, maybe a little less, depending on a lot of details. For heavy computation, Python will be a couple orders of magnitude slower than both.

To be fair, Python offloads its heavy lifting to C libraries - NumPy and SciPy run at very close to full C speed on large datasets. This is also how Matlab works. Unladen Swallow is an upcoming JIT compiler for Python. Where Haskell shines for computation is when you can leverage lazy evaluation. Cheers, G

On Fri, Nov 6, 2009 at 4:58 PM, Felipe Lessa wrote:

On 11/6/09, Gaius Hammond wrote:

...

To be fair, Python offloads its heavy lifting to C libraries - NumPy and SciPy run at very close to full C speed on large datasets. This is also how Matlab works. Unladen Swallow is an upcoming JIT compiler for Python.

Where Haskell shines for computation is when you can leverage lazy evaluation.

*If* you can offload most of your work to SciPy. Depending on what you do this is at least difficult. I don't know how much of a neural network can be represented as big fat matrix :).

-- Felipe.

Neural networking can be easily handled in both Python and C. I've used my own Graphine graph theory package for it and found that it was quite easy and reasonably fast, and certainly LEDA is a very high performance, pretty easy-to-use library. There's no need to coerce ANNs into a matrix form if you don't want to. Geremy Condra

On 21/11/2009, at 15:36 , Jon Harrop wrote:

The long-standing bug in GHC's garbage collector that makes writing a single boxed value into an array O(n) instead of O(1), because the GC dirties and retraverses the entire array, makes it impossible to write efficient Haskell code to solve many basic problems.

Are you talking about http://hackage.haskell.org/trac/ghc/ticket/650 ? The way I read that ticket is that writing a boxed value to a mutable array is still O(1), but the garbage collector traverses the whole array during scanning. That could certainly slow down GC cycles, but how does it make array update O(n)? (update of the standard Haskell "pure" arrays being a separate issue, of course). Ben.

On 21/11/2009, at 21:13 , Nicolas Pouillard wrote:

Excerpts from Ben Lippmeier's message of Sat Nov 21 07:38:09 +0100 2009:

...

On 21/11/2009, at 15:36 , Jon Harrop wrote:

...

The long-standing bug in GHC's garbage collector that makes writing a single boxed value into an array O(n) instead of O(1), because the GC dirties and retraverses the entire array, makes it impossible to write efficient Haskell code to solve many basic problems.

Are you talking about http://hackage.haskell.org/trac/ghc/ticket/650 ?

The way I read that ticket is that writing a boxed value to a mutable array is still O(1), but the garbage collector traverses the whole array during scanning. That could certainly slow down GC cycles, but how does it make array update O(n)?

He means in worst case. Writing once, will cause O(n) during the next GC. Of course if you do a lot of updates between two GCs their is no extra penalty. So if you make 'k' updates between 2 GCs it costs you k*O(1)+O(n) which is still O(n) but practically nicer than k*O(n).

Hmm. I'd be careful about conflating algorithmic complexity with memory management issues. By the above reasoning, if I were to run any program using arrays on a system with a two space garbage collector (which copies all live objects during each GC) I could say the worst case algorithmic complexity was O(n). That doesn't sound right. I could take this further and say that in a virtual memory system, there is a chance that the whole heap gets copied to the disk and back between each array update. I might again say this has O(n) complexity, but it wouldn't be very helpful... Ben.

On Saturday 21 November 2009 11:56:09 Ben Lippmeier wrote:

Hmm. I'd be careful about conflating algorithmic complexity with memory management issues.

No need. Just look at how badly the performance scales for Haskell vs other languages. For example, inserting 1-16 million floating point key/values into a hash table: Haskell OCaml F# 1M: 3.198s 1.0x 1.129s 1.0x 0.080s 1.0x 2M: 8.498s 2.7x 2.313s 2.0x 0.138s 1.7x 4M: 25.697s 8.0x 4.567s 4.0x 0.281s 3.5x 8M: 97.994s 30.6x 10.450s 9.3x 0.637s 8.0x 16M: 388.080s 121.4x 23.261s 20.6x 1.338s 16.7x Note that Haskell is 290x slower than F# on that last test. In practice, you would turn to a purely functional dictionary in Haskell based upon balanced binary trees in order to work around this long-standing bug in the GC but those trees incur O(log n) indirections and typically run orders of magnitude slower than a decent hash table. Suffice to say, Haskell is nowhere near being in the ballpark of C++'s performance for basic functionality like dictionaries and sorting.

By the above reasoning, if I were to run any program using arrays on a system with a two space garbage collector (which copies all live objects during each GC) I could say the worst case algorithmic complexity was O(n). That doesn't sound right.

Can you write a program that demonstrates this effect as I did?

I could take this further and say that in a virtual memory system, there is a chance that the whole heap gets copied to the disk and back between each array update.

Can you write a program that demonstrates this effect as I did? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e