This is a quick post to announce the first version of hpc-coveralls, a small project I’ve been working on during the past few weeks, which provides functionality to send hpc code coverage report for Haskell projects to coveralls.io.
In order to use hpc-coveralls with Travis CI, you just have to add the following commands to your
1. Install of hpc-coveralls in the before_install section:
- cabal install hpc-coveralls
2. Configure cabal for code coverage in the script section:
- cabal configure --enable-tests --enable-library-coverage - cabal build - run-cabal-test [optional-cabal-test-arguments]
Note that you have to use the
run-cabal-test command instead of the usual
cabal test command, as hpc 0.6 makes the build fail (bug which should be fixed in hpc 0.7, not yet available on Travis CI).
3. Finally, call hpc-coveralls in the after_script section:
- hpc-coveralls [your-test-suite-name]
Please note that there is currently one limitation: due to the fact that Coveralls doesn’t support yet partial line coverage, hpc-coveralls uses the following convention to convert hpc detailed coverage information into coveralls line hit count:
0: the line is never hit,
1: the line is partially covered,
2: the line is fully covered.
All contributions are welcome, so fork me on GitHub!
It is now two months since I started learning Haskell, primarily by solving Project Euler problems and reading Learn You a Haskell for Great Good. With now a little more than 30 solutions implemented in Haskell, out of the 90 that I’ve solved so far, I’m becoming more familiar with the language. After a four-year break in solving Project Euler, this fresh restart has been mind opening.
The last period during which I regularily solved problems, I was using Clojure, transitioning from using Ruby with which I had implemented my first 60~ solutions. As a starting point to learn Haskell, I thought it would be a good idea to try porting the code from my solutions originally implemented in Clojure. I soon realized the code I wrote at that time was quite difficult to understand, and the problem was recursion: a good part of the algorithms were implemented with explicit recusion using the
Recursion may well be one of the functional programming foundations, but it seems to sometimes make algorithms even more difficult to understand than data mutating for-loops in imperative programming languages.
After starting to implement new solutions for unsolved problems, I’ve found that Haskell made it really easy to avoid explicit recursion to write complex algorithms, by instead using higher order functions such as
zipWith, and other list combinators.
The fact that functions are curried by default also allows to chain composed functions in a very succinct way as opposed to Clojure in which one would have to use
partial in order to curry functions, or write anonymous functions.
All this conforts me in thinking that Haskell is a very good language to implement functional algorithms using elegant abstractions.
Finally, I’ve found that the performance of Haskell was better and far more predictable than Clojure, allowing to spend more time focusing on algorithms core logic rather than implementation details and performance tuning, which Clojure dynamic nature makes quite obscure.
This said, I’d really like to soon move on some real world project to get a better idea of what it is to develop software with Haskell.
Solving Project Euler problem 204 turned out to be rather simple for a problem in the 200~ series.
Counting generilized Hamming Numbers is similar to counting coin combinations in problem 31, but with products instead of sums.
Below is the original sum counting algorithm:
sumCombinationCount 0 _ = 1 sumCombinationCount _  = 0 sumCombinationCount r (c:cs) = if r < 0 then 0 else sumCombinationCount (r - c) (c:cs) + sumCombinationCount r cs
Adapting the recursive algorithm from sum counting to product counting is quite straightforward:
prodCombinationCount limit = prodCombinationCount' 1 1 where prodCombinationCount' count _  = count prodCombinationCount' count p (m:ms) = if p > limit then count - 1 else prodCombinationCount' (count + 1) (p * m) (m:ms) + prodCombinationCount' 0 p ms
Within the given conditions of the problem, this algorithm runs in roughly half a second on my laptop.
Below is the code for a standalone solution:
The full solution is also available on my Project Euler Haskell solutions repository on GitHub.
To go one step further, the problem can also be solved by using logarithms to transform the product counting problem into a sum counting problem. Kudos to those who came up with this approach!
After earning the “Daring Dozen” award on this one – 12 problems of 3-digit IDs – I’m now only 13 solutions away from reaching level 4. There’s no time to rest!
Welcome to my blog, Monadic Ripples, in which I will mostly write about programming related topics.
This blog is meant to be a revival of the previous blogspot one that I stopped updating already more than 3 years ago. In this new version, I will use Jekyll with GitHub Pages, which will simplify many things.
In the next few weeks, I will try to import the posts from that previous blog, explaining why some posts are older than this one.