I was curious about some statistics related to Project Euler and how well Haskell holds up in the contest. The table lists the most-often solved problems (in Haskell and overall). The question was to see if some problems are "easier" to solve in Haskell than in other languages.

Scraper

I put together a quick scraper in Haskell + tagsoup. You can find it here. If there is some interest in these kind of stats, I think I'll clean it up and look for more interesting correlations. ;-) In order to use the script, you need to be logged into ProjectEuler with a cookie set. Run this first (replacing USERNAME and PASSWORD): $ mkdir ~/.cookies/ $ curl --cookie-jar ~/.cookies/euler --data "username=USERNAME&password=PASSWORD&login=Login" "http://projecteuler.net/index.php"

Stats

Here's the first question I wanted to answer: what problems are "easier" to solve in Haskell? Given all users on Project Euler who have selected their language of preference as "Haskell", the first column gives us a percentage of how many solved the problem (second column). The third column is for comparison a ranking of difficulty of problems as judged by all languages.

% Haskelled	Haskell Rank	Euler Rank
98%	1		1
95%	2		2
89%	6		6
87%	5		5
85%	3		3
84%	4		4
83%	7		7
78%	9		8
78%	8		9
73%	10		10
73%	16		16
72%	20		20
67%	13		13
60%	25		11
58%	14		14
55%	11		12
54%	48		25
54%	15		15
54%	12		48
50%	21		18
47%	18		21
47%	22		17
46%	17		22
45%	30		19
44%	28		28
44%	24		30
43%	29		24
41%	36		67
40%	34		36
40%	19		29
39%	67		34
36%	40		35
35%	35		23
34%	52		40
33%	56		42
32%	97		27
32%	53		52
32%	23		45
31%	31		26
31%	42		31
31%	27		39
31%	45		37
31%	26		33
30%	39		53
28%	33		97
28%	37		56
28%	41		41
27%	55		32
26%	32		79
24%	38		55

More stats

In the top 50, there is almost no difference. But maybe some bigger patterns can emerge. Here's the entire list of problems, sorted by how many Haskellers solved it: [1, 2, 6, 5, 3, 4, 7, 9, 8, 10, 16, 20, 13, 25, 14, 11, 48, 15, 12, 21, 18, 22, 17, 30, 28, 24, 29, 36, 34, 19, 67, 40, 35, 52, 56, 97, 53, 23, 31, 42, 27, 45, 26, 39, 33, 37, 41, 55, 32, 38, 79, 63, 47, 43, 49, 46, 50, 59, 57, 44, 92, 69, 99, 58, 71, 81, 76, 65, 73, 62, 54, 74, 85, 112, 72, 51, 61, 70, 102, 87, 80, 82, 64, 124, 68, 77, 60, 89, 206, 66, 104, 75, 96, 83, 120, 116, 123, 91, 113, 78, 145, 117, 205, 114, 125, 108, 119, 115, 100, 95, 187, 93, 94, 179, 86, 204, 173, 90, 122, 107, 101, 203, 121, 110, 84, 191, 109, 98, 88, 164, 131, 188, 105, 132, 118, 103, 207, 174, 162, 148, 111, 137, 134, 183, 169, 138, 197, 151, 130, 139, 135, 133, 129, 106, 127, 225, 214, 149, 190, 166, 140, 136, 215, 128, 178, 231, 230, 172, 144, 211, 159, 155, 220, 158, 142, 216, 209, 165, 160, 126, 146, 202, 185, 235, 168, 150, 182, 234, 157, 221, 186, 171, 152, 141, 222, 200, 181, 176, 147, 189, 180, 175, 219, 217, 199, 154, 227, 226, 218, 213, 210, 193, 170, 208, 192, 156, 143, 196, 184, 161, 228, 201, 167, 163, 212, 194, 153, 232, 177, 195, 223, 198, 224, 236, 233, 237, 229, 239, 238] This has just been a teaser, maybe we can draw out some interesting correlations. Look forward to more stats! Suggestions, ideas, criticisms...?

Thanks to the generous folks at community.haskell.org, hback now has a public darcs repo! The hback googlecode page has been updated to reflect this. Google's SVN is no longer officially supported, so do update your sources. Checkout the source: darcs get --partial http://code.haskell.org/hback/ In other news, I'm still swamped with school work, but will be back to working on hback by the end of next week. Stay tuned! Also, if you haven't recently checked the comments from the original post, you really ought to! The readers have raised some questions and made quite a few good arguments about protocols and limitations of dual n-back tests.

hback-0.0.tar.gz Update: Released hback-0.0.2 Download Latest: hback-latest.tar.gz

Based on a recent research paper that claims fluid intelligence could be improved by training working memory, I wrote up a dual n-back test memory game in Haskell and gtk2hs. This is an alpha release: all comments are most welcome.

Gameplay

The n-back memory game tests whether the player can remember if the nth previous turn matches the current one. The dual n-back test will measure how well the player can remember both visual and graphic stimuli simultaneously.

Given a difficulty level n, the player is expected to remember on each turn whether the nth previous sound or graphic (or both) matches the current one, and toggle the appropriate button(s). The graphic flashes for 500ms and the player has another 2.5 seconds to answer.

The training game consists of b block iterations, where each block will present (20+n) visual and audio stimuli. After each iteration, the difficulty of the n-back test may increase or decrease, depending on the performance of the player: the goal is to constantly keep the player at peak concentration.

Installation

Download hback-latest.tar.gz

 % tar -xzf hback-0.0.tar.gz
 % cd hback-0.0

Game can be played without system-wide installation:

 % make trial
 % ./hback

If you like what you see, feel free to install it:

 % make build
 % make install    # you may need root privileges for this
 % rehash
 % hback

hback takes two optional arguments:

 % ./hback b n
     - b determines the number of block iterations (eg. try 20 for an effective daily workout)
     - n determines the initial level (defaults to 1)

Errata

• Playing sounds currently through mplayer. If mplayer is not installed or you prefer a different player (all the sound files are .wav), currently the user needs to edit hback.hs (function playSound :: Audio -> IO ()) and recompile. This will be fixed as soon as I think of a good cross-platform solution; any suggestions?

I've updated the hlean program. Aside from some cosmetic changes, documentation, and cabal package options, the main change is the segmentation fault fix. The program now correctly builds as a cabal package and runs. See hlean for a full description and usage details. You can download hlean 0.1.12 here. See the included README.txt for installation instructions.

Here's a very simple Haskell program:

import System.Console.Readline

main :: IO ()
main = do
  putStr "Key: "
  k <-  readKey
  putStrLn [k]

Looks pretty innocent, right? And it runs just fine with runhaskell. But as soon as you try to compile it with ghc and run it, Segmentation Faults occur. This was a bug that recently bit me with my hlean program.

What is the difference between the two? runhaskell invokes ghci, which makes additional readline initializations before handing it off to your main. The documentation is non-existent, so here is what you need to do in case you come across the same problem:

import System.Console.Readline

main :: IO ()
main = do
  initialize     -- System.Console.Readline.initialize :: IO ()
  putStr "Key: "
  k <-  readKey
  putStrLn [k]

Again, you test it using runhaskell and everything works fine. Except when you build and run it, the prompt just sits there - no matter how many times you hit that key - until you hit the carriage return (for the younger generation, that's [Enter]). Turns out that initializing Readline is not enough, ghc and ghci have different buffering modes. After even more struggling which you now don't have to suffer through, here's the final solution:

import System.Console.Readline
import System.IO

main :: IO ()
main = do
  initialize     -- System.Console.Readline.initialize :: IO ()
  hSetBuffering stdin NoBuffering   -- System.IO
  hSetBuffering stdout NoBuffering  -- System.IO
  putStr "Key: "
  k <-  readKey
  putStrLn [k]

Hope I saved some poor googler some time and stress - I know I would have appreciated finding a post like this earlier. Kudos to pejo and dcoutts on #haskell irc for helping me sort this out.

UPDATE: hlean 0.1.2 available I needed a program to find duplicate files in my constantly growing jungle, commonly referred to as a $HOME directory. I also needed a real motivation to sit down and write something in Haskell. After several cups of tea, I realized I could kill both birds with one heavy laser-targetting sniper rifle. After all, isn't that what they say about Haskell: once you can get it to compile, you're almost done? hlean.hs is a command line program that takes any number of directories passed as arguments, recursively find all files, hashes them (defaults to sha256), and asks what to do with any duplicate sets found. It works fine for me, but since this is the first release, there are certainly some rough edges and caveats. Additionally, only you are responsible for your data; use this at your own risk: I cannot be held responsible if your computer blows up in a freak fire accident and coincidentally all the monkeys escape from the zoo. Rough edges:

• All the Haskell hash function libraries I've tried are either too slow or don't handle large files very well, hence I was currently forced to use an external command line hashing function.
• sha256 is the default command line hash. If you are not running FreeBSD, you will most likely need to modify two functions: hashCommand and hashCommandParse.
• Eventually, I will either find a suitable Haskell library or make a more user-friendly configuration setup.
• The "move file" action does not give the user a nice shell-like directory tab autocomplete. It would be nice to find a Readline prompt that does.

Ugliness:

• I've made a cabal package, but currently the ghc compiled version seg faults. The runhaskell version works perfectly fine, which has left me very confused. I will look into this more when I have the time, but I've uploaded both versions in case someone would like to help me debug the issue. Fixed in hlean 0.1.2

Haskell: hlean.hs Cabal Package: hlean-0.1.1.tar.gz Usage: runhaskell hlean.hs [dirs] Feel free to leave any comments, bug reports, or feature requests.