ANNOUNCE: dimensional-0.10

I just released version 0.10 of the dimensional library, adding an Enum instance for quantities. Thus now it is possible to, e.g.:

> import Numeric.Units.Dimensional.Prelude
> import qualified Prelude

> xs = [1 *~ meter..]  -- [1 m, 2 m, 3 m...]

However, I just realised that the behaviour may occasionally be surprising unless one keeps in mind that the default increment will be a product of SI base units and the value 1. For example:

> ys = [1 *~ kilo meter..]  -- [1000 m, 1001 m, 1002 m...]

In order to avoid shooting oneself in the foot I recommended sticking with the enumFromThen or enumFromThenTo forms:

> zs = [1 *~ kilo meter, 2 *~ kilo meter..]  -- [1000 m, 2000 m, 3000 m...]

Another option is to use *~~ (see my previous post):

> zs' = [1..] *~~ kilo meter  -- [1000 m, 2000 m, 3000 m...]

In other news I’ve added a “search this blog” widget to the right to help myself find my pandoc article that I need to refer to every time I post. Feel free to use it!

ANNOUNCE: dimensional-0.9

I am pleased to announce version 0.9 of my dimensional library for arithmetic with statically checked physical dimensions. The differences from version 0.8.2.1 is the specification of fixity for *~~ and /~~ and their generalization to operate on functors rather than lists. The lack of fixity specifications was a bug; I had always intended them to have the same fixity as the closely related *~ and /~ (and * and / for that matter).

For readers unfamiliar with the above operators they are used to relate numerical values with units in order to construct and deconstruct physical quantities. For example:

> import Numeric.Units.Dimensional.Prelude
> import qualified Prelude

> x :: Length Double  -- type Length = Quantity DLength
> x = 1 *~ meter

> y :: Double
> y = x /~ kilo meter  -- 0.001

This convention for constructing and deconstructing quantities by multiplication and division respectively is motivated by the NIST Guide to the SI, section 7.1.

The *~~ and /~~ operators are analogous to *~ and /~ but operate on functors, e.g.:

> xs :: [Length Double]
> xs = [1..] *~~ meter

> ys :: [Double]
> ys = xs /~~ kilo meter

Finally an observation for the Haskell community: the Haskell package versioning policy does not address fixity changes, which I presume should force a major version change. Unless someone either objects or beats me to it I will update the wiki to reflect this.

ANNOUNCE: normaldistribution-1.1 – Minimum fuss normally distributed random values.

I’m pleased to announce the immediate availability of the normaldistribution library on hackage.

This purpose of this library is to have a simple API and no dependencies beyond Haskell 98 in order to let you produce normally distributed random values with a minimum of fuss. This library does not attempt to be blazingly fast nor to pass stringent tests of randomness. It attempts to be very easy to install and use while being “good enough” for many applications (simulations, games, etc.). The API builds upon and is largely analogous to that of the Haskell 98 Random module (more recently System.Random).

Pure:

> (sample,g) = normal  myRandomGen  -- using a Random.RandomGen
> samples    = normals myRandomGen  -- infinite list
> samples2   = mkNormals 10831452   -- infinite list using a seed

In the IO monad:

> sample    <- normalIO
> samples   <- normalsIO  -- infinite list

With custom mean and standard deviation:

> (sample,g) = normal'    (mean,sigma) myRandomGen
> samples    = normals'   (mean,sigma) myRandomGen
> samples2   = mkNormals' (mean,sigma) 10831452

> sample    <- normalIO'  (mean,sigma)
> samples   <- normalsIO' (mean,sigma)

Internally the library uses the Box-Muller method to generate normally distributed values from uniformly distributed random values. If more than one sample is needed taking samples off an infinite list (created by e.g. normals) will be roughly twice as efficient as repetedly generating individual samples with e.g. normal.

Update 2011–04–09: Changed to reflect version 1.1.

Update 2011–04–22: Version 1.1.0.1 released which builds with haskell98-1.1+ (GHC-7.0.1+). No code changes.

Flattrable Reactive Programming

I have occasionally seen these “flattr this!” buttons, notably on the blog of Luke Palmer, and occasionally felt it was exactly what I wanted to do. However, inertia always got the better of me – no doubt I was busy being distracted by some lolcat screaming for adoration.

Lately I noticed a flattr button on the blog of Heinrich Apfelmus too, and again felt a desire to give. Heinrich’s blog was the tipping point (pun intended) that finally got me to actually visit flattr.com, and this great quote from Alexandros closed the sale:

This month, thanks to Flattr, I’we shared my world to the world. I earned 0.03 cents - the best 0.03 cents ever!

How can that not make me want to give? (Is Alexandros being sarcastic? He looks happy enough in his profile pic…)

My first flattrs go to Luke and Heinrich; 0.03 cents are coming your way! ;)

Alexandros gets flattred too. And now that I’ve signed up I’ll be on the lookout for more flattr buttons (so don’t feel bad if you weren’t mentioned here!).

As an aside, the common denominator that made me want to flattr Luke and Heinrich is their efforts to explore Functional Reactive Programming. It seems to me that much remains to be discovered in the FRP design space and I hope my flattrs encourage these brave explorers to push the boundaries further… Oh, look! Conal Elliott has a flattr button too!

Dimensional example: leaky container pressure

Herein I demonstrate a calculation performed today in my work. The details are slightly different to protect the innocent but the problem is the same. The purpose of all this is to demonstrate use of the dimensional library. What this blog post unfortunately fails to demonstrate is how the compiler helps catch errors in units and formulae, effectively double-checking any derivations for me – this is the real value of dimensional! In case you have never heard of dimensional before here is the blurb from the project site:

Dimensional is a library providing data types for performing arithmetic with physical quantities and units. Information about the physical dimensions of the quantities/units is embedded in their types and the validity of operations is verified by the type checker at compile time. The boxing and unboxing of numerical values as quantities is done by multiplication and division with units. The library is designed to, as far as is practical, enforce/encourage best practices of unit usage.

This is a literate Haskell program. You can copy and paste this blog post into a .lhs file and it should compile and run (provided you have installed dimensional). First the formalities:

> import Numeric.Units.Dimensional.Prelude
> import Numeric.Units.Dimensional.NonSI
> import qualified Prelude

(In the below I have used parentheses rather than juxtaposition to denote function application for functions of time, e.g. p(t). Does this help or hurt clarity given the subject matter?)

Consider a leaky container of volume v filled with gas to pressure p₀ and launched into space at time t₀ (insert favorite monad tutorial joke here). There is a requirement that at some future time t₁ said container must retain no less than a given amount of gas. The temperature T of the container is held constant by a thermal control system so per the ideal gas law (a good enough approximation) we can characterize the requirement to remnant gas by its pressure p_min. The problem at hand was to determine the maximum allowable leak rate of the container at t₀ to ensure that the pressure at time t₁ is no less than p_min.

Here are the inputs (don’t blame me for the choice of units, this is what I was given):

> v     =      2 *~ liter
> t_0   =      0 *~ hour
> p_0   =    750 *~ mmHg  -- roughly atmospheric pressure
> t_1   = 133650 *~ hour  -- about 15.25 years
> p_min =      5 *~ mmHg
> temp  = fromDegreeCelsiusAbsolute 22

For slow leakage it can be assumed that the leakage rate is proportional to the pressure of the gas inside the container (more generally, the pressure difference between the gas in the container and the surrounding medium). Thus the rate of change of the pressure is described by the first order linear differential equation

> dpdt(t) = negate k * p(t)

with solution

> p(t) = c * exp (negate k * t)

The integration constant c is determined from the initial conditions at t₀:

> c = p_0  -- follows from t_0 = 0 s.

We chose the worst case conditions at t₁ to determine k:

> k = log (c / p_min) / t_1

Now, per the ideal gas law the amount of substance n in the container is described by

> n(t) = p(t) * v / (r * temp)

where

> r = 8.314472 *~ (joule / (mole * kelvin))

is the ideal gas constant. Differentiating n(t) give the rate of change of substance in the container:

> dndt(t) = dpdt(t) * v / (r * temp)

and the maximum allowed rate of change (leakage rate) at time t₀ is produced by

> main = print (dndt t_0)  -- -8.486687441280605e-10 s^-1 mol

That’s it!

ANNOUNCE: numtype 1.0 — Type-level (low cardinality) integers

Since its inception my dimensional library has been built around a unary type-level representation of integers (NumTypes) defined in the Numeric.NumType module. This module has proven itself useful outside the context of dimensional and after dragging my feet for a long time I’ve finally gotten around packaging it up in its own library: numtype.

The Numeric.NumType module is completely self-contained (only imports Prelude) and is heavily commented in a narrative manner inspired by Oleg Kiselyov’s expositions. I believe it provides a good case study for type-level programming with multi-parameter type classes (MPTCs) and functional dependencies.

Addition, subtraction, division, and multiplication of NumTypes is supported. NumTypes have no value-level representation but can be converted to any Num instance with the toNum function.

The numtype library has two significant short-comings:

• Minimal haddocks — as with my dimensional library the literate Haskell source code is the documentation. The flip-side is that the code is very well-commented.

• Due to the unary implementation the practical size of the NumTypes is severely limited, making them unsuitable for large-cardinality applications. If you will be working with integers beyond (–20, 20) this package probably isn’t for you.

(If the second bullet is a show-stopper Edward Kmett’s type-int library may be a better choice. Peter Gavin’s tfp library also provides type-level integers but uses type families instead of MPTCs and fundeps. I cannot vouch for either of these libraries as I haven’t used them.)

Numtype version 1.0 can be downloaded from Hackage or the dimensional project page. I’ve also updated dimensional to version 0.8 with the Numeric.NumType module removed and Julian year and century units added. Enjoy!

Benchmarking Amazon EC2 with GHC

My personal computers are pretty old and/or slow. I have an old PowerBook G4 and a newish EEE PC. The PowerBook was top of its class when I got it with most options maxed out. Alas, that was five years ago. The EEE PC is by definition not a top performer, nor does it try to be. I find that when the two machines perform similarly in day-to-day tasks, at least when the EEE PC is in “Super performance” mode.

Truth is that for most of the mundane stuff I do these two machines perform acceptably. I’m obviously not going to be watching any 1080p movies on them, or enjoying the latest games (from a productivity standpoint I’m not sure these are such bad things), but most everything else works fine.

Where I feel the performance does hurt me is when compiling with GHC (or any compiler for that matter, it’s just that GHC is the one I use most). Often I spend way to much of my precious little private developer time waiting for the compiler to finish. This is in stark contrast to the situation at work where I run GHC on a pretty zippy Dell PowerEdge Blade Server.

In the near future I expect to be spending more time developing at home and want to be able to do so more efficiently, preferably on par with the situation at work. I could obviously buy shiny new hardware but being a miser (in case you couldn’t already tell based on my hardware) I’m looking for alternatives that would allow me to avoid or defer a hefty up-front investment. One such alternative I’m considering is to rent compute capacity in the Amazon Elastic Compute Cloud (EC2).

EC2 compute capacity is sold in the form of instances at an hourly rate ranging from $0.10 to $0.80 depending on capacity/performance plus some small-change for bandwidth and persistent storage. While there are a couple of hurdles to overcome in order to leverage EC2 as a development workstation the first thing I want to do is to make sure it is a goal worthy of pursuing in the first place, i.e. will I get the desired performance gains at a reasonable price?

To at least begin to answer this question I’ve done some informal benchmarking of the aforementioned systems, excluding the pricier EC2 instances. All the regular benchmarking caveats apply and to reinforce the unscientificity of it all I’m not going to bother providing complete specs for the systems. Here are the fundamentals:

• Apple PowerBook G4: 1.5 GHz PowerPC G4 processor, 2 GB RAM, 5400 rpm HD.
• Asus EEE PC 900HA: 1.6 GHz Intel Atom processor, 1 GB RAM, 4200 rpm HD.
• Dell PowerEdge 1855 Blade Server: Two single-core 3.2 GHz Xeon processors, 2 GB RAM.
• Amazon EC2 Small Instance: 1 EC2 Compute Unit (1 virtual core), 1.7 GB RAM, $0.10 per hour.
• Amazon EC2 High-CPU Medium Instance: 5 EC2 Compute Units (2 virtual cores), 1.7 GB RAM, $0.20 per hour.

According to Amazon “one EC2 Compute Unit provides the equivalent CPU capacity of a 1.0–1.2 GHz 2007 Opteron or 2007 Xeon processor.”

I figure the results are probably more interesting that the details of the tests so here they are, the systems are ordered by increasing performance which happened to be consistent across the tests:

Benchmark results, times in seconds, shorter times are better.

	astro-tables build	highlighting-kate build	fad test suite
PowerBook G4	292	(848)	28
EEE PC	291	643	18
EC2 Small	171	519	15
Dell PowerEdge	75	260	6
EC2 Medium	55	172	4

The EEE PC was in “Super Performance” mode during the tests and the PowerBook was at its highest CPU speed. All times are the “real” time as measured by the Unix time command and lower numbers are naturally better.

As can be seen an Amazon EC2 Small instance is only marginally faster than the EEE PC. An EC2 High-CPU Medium instance on the other hand is significantly faster than the zippy Dell PowerEdge Blade server. Is either one a good deal? Good question, I think a case could be made either way depending on your priorities but I’m not going to tackle that today.

If you care about the details of the tests read on, if not please move on to your next blog of choice!

astro-tables build

This package currently consists of a single automatically generated 4000-line monster of a module¹. The code is pretty straight-forward but the module takes ages to compile, almost certainly due to me giving the type checker an unnecessarily hard time. I have a trivial rewrite on my todo-list which I expect will shorten the compilation time dramatically but the current form comes in kind of handy for the purposes of this benchmark. The Git repo is git://github.com/bjornbm/astro-tables.git and the commit used in the benchmarking was e63b8978833878526870b2101697197ff64af593. I made sure the dependencies were already installed and ran time cabal install.

highlighting-kate build

From recent memory I knew that John MacFarlane’s highlighting-kate package has a hefty number of modules (the majority of which are also automatically generated) that take a fair amount of time to compile. I downloaded version 0.2.4 from hackage, made sure all dependencies were already installed, and ran time cabal install --flags=executable.

I ran into one snag with this test: the build wouldn’t complete with GHC 6.10.3 on the PowerBook G4 due to some problem with pcre-light (which tends to give me headaches on pretty much every platform). This particular headache² I was unable to resolve and had to run the test using GHC 6.10.1 on the PowerBook G4.

fad test suite

Finally I did a runtime performance (as opposed to compilation) benchmark: running the test suite of the fad library. The Git repo is git://github.com/bjornbm/fad.git and the commit used was cd2965a6741291570930e4bf6e9f8f9ab64ccadd. I ran ghc --make Test and then time ./Test.

---

1. An implementation of the 678 lunisolar terms and 687 planetary terms of the IAU 2000A Precession-Nutation Model. ↩

2. gcc: Internal error: Virtual timer expired (program cc1) ↩