However, I have decided to use PHP.

This is a somewhat surprising choice (even surprising to myself), as I don’t like PHP. It’s a hacky language, which is horrendous. But recently I have done some work in it for the sailing club, where our results are calculated with it, and I got used to it. For all its faults, it has a good library, and is fairly flexible. You can even write programs in a kind of functional style. And it’s ubiquitous on the web, so if I ever want to run my system (or parts of it) on the web, I should have no problems doing so.

You can run it pretty easily (just with php YOUR-FILE), so you don’t need to worry about build files or class paths or other complicated stuff. And it’s portable.

In a way it’s a very simple and straightforward language, so I can pretty much focus on what I want to do, and don’t need to worry about the how. I’ll see how it goes, but so far I’m quite happy with it. Especially since I realised how to call any function based on its name, which means I re-invented some kind of object system… if an object (a plain array) has a key “fn_print”, then that is used to print itself. Very easy and nifty. Similarly I can compose function names from some other values, and then call a function. I can even check if it exists, and fall back to a default if not.

Yes, with other languages you get that kind of thing for free, but sometimes it is easiest to take what’s in front of you. I have railed against PHP in the past, and it’s not a good language, but it’s there, it’s everywhere, and it’s easy to use. So let’s see how I get on with a larger project!

You have 4 bags, each full of the numbers 1, 3, 5, and 7 respectively. Take 10 of the numbers that when added up make 37. What numbers are they?

So far so good: that sounds easy enough. But a bit of trial and error quickly leads nowhere. Something can’t be right. So, let’s get the computer to work it out.

As I haven’t done much Erlang recently I thought I’d give it a go. And, during a casual glance at Armstrong’s Programming in Erlang I thought I’d finally understood list comprehensions, so I wrote the following program:

-module(comb).
-export([result/0]).
result() ->
[{A+B+C+D+E+F+G+H+I+J,A,B,C,D,E,F,G,H,I,J}||
A <- [1,3,5,7],
B <- [1,3,5,7],
C <- [1,3,5,7],
D <- [1,3,5,7],
E <- [1,3,5,7],
F <- [1,3,5,7],
G <- [1,3,5,7],
H <- [1,3,5,7],
I <- [1,3,5,7],
J <- [1,3,5,7],
A+B+C+D+E+F+G+H+I+J =:= 37].

I declare a module with one function, result/0. This finds me ten variables that can take any of the four specified values and add up to 37. Simples!

The list comprehension has ten generators, and one filter; it will return a tuple with the sum and the individual variables’ values.

Erlang R16B01 (erts-5.10.2) [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false]
Eshell V5.10.2 (abort with ^G)
1> comb:result().
[]
2>

WTF???! An empty list?! So I try changing the 37 to another value, like 36.

3> comb:result().
[{36,1,1,1,1,1,3,7,7,7,7},
{36,1,1,1,1,1,5,5,7,7,7},
{36,1,1,1,1,1,5,7,5,7,7},
{36,1,1,1,1,1,5,7,7,5,7},
{36,1,1,1,1,1,5,7,7,7,5},
[etc, etc].

So it does work! Only, there doesn’t seem to be an answer to the question. And with a bit of logical reasoning it is obvious: when adding two odd numbers, you get an even number. So adding ten odd numbers also yields an even number, but 37 is odd.

What I learnt from this exercise: thinking about the problem beforehand can save you time, as there was no need to write a program at all. But then, I did get to use list comprehensions, and have learnt how powerful they are. And it neatly shows Erlang’s Prolog roots as well.

Originally the class property in question was going to be set in the init method, so I tested for the presence of the property after creating an instance of the relevant class. Easy pass. Weeks later I did something (and forgot to run the test suite). Today I did something else, and this time I did run them. Hey presto, failed test. And completely unexpected, because it was the property exercising one. How on Earth did that happen?

Upon closer inspection I tracked it down to a refactoring, where I extracted some code from init as there were now multiple ways an object could be initialised. The failing code was part of that, and I realised that it was called from the new initFromFile: method, but no longer from the default initialiser. Easy mistake to make. And had I run my test-suite more consistently, my application would not have been with a potential bug in the meantime.

What did I take home from this?

• Even Mickey-Mouse-tests are valuable. No test is too small to be useful (provided it’s actually testing something valid).
• The test-suite should really be run after every change. I’ll have to check if I can get Xcode to run them automatically after each compilation…

Update: Since I stopped doing much iOS or Mac OS work, I no longer used Xcode. And I’m not missing it :)

1> lists:seq(1,4).
[1,2,3,4]
2> lists:seq(634,637).    
[634,635,636,637]
3> lists:seq(1000,1003).
[1000,1001,1002,1003]

Now I would simply generate a list with a number for each row, and then send the inner loop off to do its thing, filling the slot given by the sequence number with a zero, and others with a random value.

But now it gets even better. Using a separate (tail-)recursive function for the inner loop didn’t quite seem right, so I thought a bit more about it and came to the conclusion that this is simply a mapping; mapping an integer to a list (a vector of numbers, one of which (given by the integer) is a zero). So instead of using a function for filling the row, I call lists:seq/2 again and then map the whole thing. This is the final version I arrived at, and I’m sure it can still be improved upon using list comprehensions:

random_matrix(Size, MaxVal) ->
  random:seed(),
  lists:map(
    fun(X) ->
      lists:map(
          fun(Y) ->
              case Y of 
                 X -> 0; 
                 _ -> random:uniform(MaxVal)
                 end
              end,
          lists:seq(1,Size))
      end,
    lists:seq(1,Size)).

This solution seems to be far more idiomatic, and I am beginning to think that I finally no longer think in an imperative way of loops, but more in the Erlang-way of list operations. Initially this is hard to achieve, but with any luck it will become a lot easier once one is used to it. Elegance, here I come!

Example run:

4> random_matrix(6,7).  
[[0,1,4,6,7,4],
 [3,0,5,7,5,4],
 [5,1,0,2,5,2],
 [4,2,4,0,3,1],
 [4,4,3,3,0,1],
 [5,7,3,2,2,0]]

Note: I have used random:seed/0 above, as I am happy for the function to return identical matrices on subsequent runs with the same parameters. To get truly random results, that would have to be left out. However, for my benchmarking purposes it saved me having to save the matrix to a file and read it in, as I can easily generate a new copy of the same matrix I used before.

Pathfinder Networks (PFNETs) are networks derived from a graph representing proximity data. Basically, each node is connected to (almost) every other node by a weighted link, and that makes it hard to see what’s going on. The Pathfinder algorithm prunes the graph by removing links which are weighted higher than another path between the same nodes.

For example: A links to B with weight 5. A also links to C with weight 2, and C links to B with weight 2. Adding up the weights, A to B direct is 5, A to C to B is 4. Result: we remove the link from A to B, as the route via C is shorter. There are different ways to calculate the path lengths (using the Minkowski r-metric), but you get the general idea. The resulting PFNET has fewer links and is easier to analyse.

In Schvaneveldt (1990) an algorithm for computing PFNETs is given, but it is rather complex and computationally intensive. There is an improved algorithm called Binary Pathfinder, but that is apparently more memory intensive. Not very promising so far, but then along comes A new variant of the Pathfinder algorithm to generate large visual science maps in cubic time, by Quirin, Cordón, Santamaría, Vargas-Quesada, and Moya-Anegón. This algorithm is a lot faster (by about 450 times), but has one disadvantage: speed is traded in for flexibility. The original Pathfinder algorithm has two parameters, r (the value of the Minkowski metric to be used) and q (the maximum length of paths to be considered). The fast algorithm only has r, and always uses the maximum value for q (which is n-1). I know too little about the application of PFNETs to say whether this is important at all; for the uses I can envisage it does not seem to matter.

As added bonus, the algorithm in pseudo code in Quirin et al. is very short and straightforward. They’re using a different shortest-path algorithm to identify, erm, shorter paths. And then it’s very simple to prune the original network.

A picture tells more than 1K words, so here instead of 2000 words the before and after, graph layout courtesy of the graphviz program:

A network example (from Schvaneveldt 1990)

Here, each node is linked to every other node. Running the PFNET algorithm on it, we get the output shown in the second figure.

A PFNET generated from the previous graph:

If you compare the output with the actual result from Schvaneveldt’s book (p.6 / 7), you’ll realise that it is not identical, and the reason for that is that the example there limits the path-length, using the parameters (r = 1, q = 2) rather than (r = 1, q = n-1) as in the example shown here. As a consequence, the link from N1 to N4 (with a weight of 5) disappears, because of the shorter path (N1-N2-N3-N4, weight 4). But that path is too long if q is just 2, and so it is kept in Schvaneveldt’s example.

Implementation

It is not possible to implement the pseudo-code given in Quirin et al directly (in Erlang), as they use destructive updates of the link matrix, which we obviously cannot do in Erlang. But the first, naïve, implementation is still quite short. The input graph is represented as a matrix (n x n) where each value stands for the link weight, with zero being used to indicate non-existing links. I have written a function that creates a dot file from a matrix, which is then fed into graphviz for generating images as the ones shown above.

There are basically two steps: creating a matrix of shortest paths from the input matrix, and then generating the PFNET by comparing the two matrices; if a certain cell has the same value in both matrices, then it is a shortest path and is kept, otherwise there is a shorter path and it’s pruned. Here is the main function:

find_path(Matrix) ->
    Shortest = loop1(1,length(Matrix),Matrix),
    generate_pfnet(Matrix, Shortest, []).

Next we have the three loops (hence ‘cubic time’!) of the Floyd-Warshall shortest path algorithm to create the shortest path matrix:

loop1(K,N,Matrix) when K > N -> 
    Matrix;
loop1(K,N,Matrix) ->
    NewMatrix = loop2(K,1,Matrix,
        Matrix,[]),
    loop1(K+1,N,NewMatrix).

loop2(_,_,_,[],Acc) ->
    lists:reverse(Acc);
loop2(K,I,D,[Row|Rest],Acc) ->
    NewRow = loop3(K,I,1,D, Row, []),
    loop2(K,I+1,D,Rest,[NewRow|Acc]).

loop3(_,_,_,_, [], Acc) ->
    lists:reverse(Acc);
loop3(K,I,J,D, [X|Rest], Acc) ->
    loop3(K,I,J+1,D, Rest,
    [min(X, get(I,K,D) + get(K,J,D))|Acc]).

The final line implements the Minkowski metric with r = 1; this could be expanded to include other values as well, eg r = 2 for Euclidean, or r = ∞ (which seem to be the most common values in use; the latter means using the maximum weight of any path component along the full path).

And here are two utility methods, one to find the smaller of two values, and one to retrieve an element from a matrix (which is a list of rows). There is something of a hack to deal with the fact that zero does not mean a very small weight, but refers to a non-existing link:

min(X, Y) when X < Y -> X;
min(_X, Y) -> Y.

get(Row, Col, Matrix) ->
    case lists:nth(Col,
      lists:nth(Row, Matrix)) of
        0 -> 999999999;
        X -> X
    end.

And finally, generating the PFNET by comparing the two matrices (again, awful hack included):

generate_pfnet([],[],Result) ->
    lists:reverse(Result);
generate_pfnet([R1|Rest1], [R2|Rest2], Acc) ->
    Row = generate_pfrow(R1,R2,[]),
    generate_pfnet(Rest1, Rest2, [Row|Acc]).

generate_pfrow([],[],Result) ->
    lists:reverse(Result);
generate_pfrow([C|Rest1], [C|Rest2], Acc) ->
    case C of
        999999999 -> C1 = 0;
        _ -> C1 = C
    end,
    generate_pfrow(Rest1, Rest2, [C1|Acc]);
generate_pfrow([C1|Rest1], [C2|Rest2], Acc) ->
    generate_pfrow(Rest1, Rest2, [0|Acc]).

Discussion

So this is the basic code. It works, but there is scope for improvement.

• it only currently generates PFNETs with (r = 1, q = n-1)
• there is no parallelism, hence it’s not really making use of Erlang’s strengths.
• the three loops don’t look very elegant, and could probably be replaced by list comprehensions

Because of the matrix being updated, it doesn’t look that easy to parallelise the processing, but it would work at the level of updating the individual rows. If that can be done in parallel, it would probably provide some speed-up (provided the matrix is not of a trivial size). So the first step would be to change the matrix processing using lists:map/2, and replacing this then by pmap.

Once the code is up to scratch with full parallelism, and tested on larger matrices I will probably put it up on Google Code in case other people are interested in using it. If you have any suggestions, tell me in the comments!

References

Schvaneveldt, R. W. (Ed.) (1990)

Pathfinder Associative Networks: Studies in Knowledge Organization. Norwood, NJ: Ablex. The book is out of print. A copy can be downloaded from the Wikipedia page

Quirin, A; Cordón, O; Santamaría, J; Vargas-Quesada, B; Moya-Anegón, F (2008)

“A new variant of the Pathfinder algorithm to generate large visual science maps in cubic time”, Information Processing and Management, 44, p.1611-1623.

Like many(?) computer people of my generation I started off with the Sinclair ZX81, and then continued with the ZX Spectrum and onwards to an Amstrad CPC, learning BASIC and Z80 machine code (because those machines were actually pretty slow). This also means that I treat computers as tools, not passively using programs other people have written, but writing my own stuff. In time I moved on with languages, from Pascal to C, a bit of Prolog, C++, Java, and now Erlang. But those endless hours typing in program listings in BASIC have surely benefitted me. Learning by doing. Type in small programs, change the code, observe what happens.

My oldest daughter is seven, still half my age when I started with computers, but from next year onwards they have ICT classes at school; these basically seem to be ‘how to change fonts in MS Word’. So I thought I’d better show her that a computer program is something you write, not just something you use. The only problem was, how to do it? Despite all its faults, BASIC seems to me to be a good language to start with. True, it has few control structures or abstract data types, but it reads almost like English, and is only a starting point after all. And it’s only a first step in any case.

The next question is how to get her interested. Using a PC seems like overkill, and you need to boot it up, and shut it down, and then start a development environment etc. And I guess it’s not that easy to use graphics or sound as it was on the old Spectrum. So, I went to ebay and bought a ZX Spectrum +2 for about £7. You plug it in, it’s on. You can start typing. You’re finished, you unplug it. No files to get corrupted. And it’s got a built-in tape recoder for storage.

And, she is really excited. It’s her very own computer, and she already knows several commands. All I need now is a few books with BASIC programs, so that she has some material to type in. In the meantime I go with her through the manual, explaining the new keywords, and she can already understand how a program is executed. With any luck she’ll get hooked, especially once she learns how to do graphics with it. And the little games (‘guess the number’) are also the right level for her, and maybe even her sisters.

The only problem I can see is printing. But I’ve got an emulator on my laptop, which might be able to read in something she saves, and I might be able to take it from there.

In the meantime, however, the need for using different platforms has become less pressing for me, as I mainly do this as a work-related hobby nowadays.

I’m having a problem with languages. Not that there is something I cannot do in my favourite language, but rather that there are distinct ecosystems for various languages, and they are usually fairly exclusive. For example, in order to program in a web context you need either PHP, or alternatively be prepared to run your own server if you want to use Java or Erlang. I’m not talking about businesses or commercial operations here, just the private/academic/small scale non-funded project range.

Most of the language processing software I’ve written is in Java, because it works well and can run almost everywhere (but not on shared webhosts). It’s useful to distribute applications, as people can use it on Linux, Macs and even Windows. But I’ve now pretty much switched to Erlang, as I put high hopes on the future of parallel programming, and I want my software to take advantage of multi-core processors. However, Erlang programs are not as easily shared and distributed as Java apps are. Problem.

Ideally I’d like to write all my programs only once. This was kind of the promise of Java, and it worked mostly. At some point I even considered working on an interpreter for JVM bytecode written in PHP (so that my Java classes would work without having to be re-coded in PHP itself), but aside from the possibly terrible performance it seemed too daunting a project. Maybe Erlang could be compiled into JVM bytecodes? Of course you’d lose all the concurrency features etc, but at least you could deploy it together with a Java app. A bit like Scala, almost. Update: There is a (defunct?) project that does attempt exactly that: Erlang on the JVM.

If PHP wasn’t such a ghastly language I’d be happy to code everything in that, but it seems too much of a sacrifice. But for most purposes I would need at least those three:

• Java for applications to be deployed to other people
• PHP for stuff running on shared webservers
• Erlang for research and cutting-edge stuff

And there is little to no common ground between them. Sigh.