Draggable-Droppable Sortable List

Friday, 18th September, 2015

Here is a demo showing Rubaxa’s Sortable used with React.

The demo is based on a trimmed down version of the React example on the Sortable github page. The extras are:

  • the list items are React classes rather than text;
  • handleEnd shows accessing re-arranged list items on drop;
  • list items have a handle, which means their contents can be assessed and manipulated.

n.b.: in the gist below, the javascript file uses JSX markup so it’ll need to be compiled (e.g. with React’s cli tools or babel).

[github gist]

I like Rubaxa’s Sortable because it (a) works! (b) does not require any silly javascript package managers.

I recently did the Elm: Building Reactive Web Apps video course by The Pragmatic Studio ($29). Here are some notes about my experience.

I enjoyed the course, and I think I learned a lot. I shall certainly be taking the Elm: Signals, Mailboxes, & Ports course when it comes out in mid-September.

The course was two hours of videos in twenty six-minute sessions. Source code and pdf summaries also available.

It used a simple project to cover the basics of

This was plenty, and made for a relaxed, uncluttered course. Presentation was clear and unfussy.

Using the StartApp module meant that the details of message-passing in Elm could be left out altogether. I think it is a good idea to treat message-passing as a topic in its own right (i.e., which they’ll be covering in their next course).

I liked the course a lot and I highly recommend it.

Brief review: The Little MLer

Sunday, 31st May, 2015

book details

“The Little MLer”
Matthias Felleisen and Daniel P. Friedman
MIT Press


I had resolved not to learn any new languages in 2015, but: I knew if I were to learn a language it would probably be ML (or some kind of proof assistant type thing); this book was on my Amazon Wish List; and MIT Press had a half price sale.

I’m afraid I was quite underwhelmed by The Little MLer. It brings upon itself comparison with The Little Schemer: the same dialogue format, the same illustrator (with “guest appearances” by the Little Schemer elephants), even occasional “in-jokes” about Lisp. It suffers greatly under this comparison.

Lisp is not a normal programming language. The basic building blocks of Lisp — list; first thing in list; rest of list — are so simple — naively, childishly simple, even romantically simple (steady on — Ed.). So the childish dialogue approach in The Little Schemer, with virtually no presuppositions really is plausible, and even appropriate. I thought the book effectively conveyed the charm and wonder of Lisp.

I’m not qualified to say much sensible about ML, but this book felt contrived — the tried and tested dialogue format forced onto an unsuspecting programming language (in the same style there’s also A Little Java and A Few Patterns). The Little Schemer was full of “stout Cortez” moments; The Little MLer had one: a brief exploration of what might have been lazy evaluation.

I have a gut feeling that ML could be an exciting language, but The Little MLer is a dull exposition following an imported schema.

My plan for this year is to bring in the clients, write the apps, and make some money. Being anything other than ruthlessly pragmatic about learning new programming languages is distinctly not part of the plan. This year is about focussing and consolidating, it is not about wandering about smelling the roses.

However, …

Separate from programming, I am following up some of my reading from last year. In particular, Hegel (I’m finally tackling his Phenomenology of Spirit) and Schrödinger (his book and Weyl’s book both look worth a try; and Schrödinger’s paper on colour looks like it might be a good introduction to some of the geometry).

Learning about the strong link between Schrödinger and Weyl was quite a revelation. Weyl was also associated with Brouwer and the intuitionist/constructivist approach to maths. The ncatlab page on constructive maths mentions Hegel in its prehistory section.

So, sometime later in the year I’ll be reading about Brouwer, his mathematical intuitionism, and constructivism. As part of that, I might be “doing” some maths.

Doing constructive maths seems to involve proofs, verifications of proofs, and even mechanisations of verifications. Things called proof assistants can be used. So quite possibly I’ll be trying out one or more of these proof assistants.

To the untrained eye these proof assistant things look a lot like programming languages.

That Giant’s Causeway puzzle in Prolog

Tuesday, 13th January, 2015

Chris Lamb published a very nice blog post the other day showing a wooden logic puzzle he’d found, and implementing a solver in Python.


It was such a nice post I thought I’d write one in Prolog. Here it is (and in a gist):

% hex tiles puzzle
% - https://chris-lamb.co.uk/posts/giants-causeway-puzzle
% - https://llaisdy.wordpress.com/2015/01/13/that-giants-causeway-puzzle-in-prolog/

:- use_module(library(clpfd)).  %% for all_different/1

%% tile(Name, Colours).

% tiles from picture
% tile(11, [red, blue, black, yellow, green, white]).
% tile(22, [white, black, yellow, green, blue, red]).
% tile(33, [green, blue, black, yellow, red, white]).
% tile(44, [white, black, red, green, blue, yellow]).
% tile(55, [white, blue, green, yellow, black, red]).
% tile(66, [white, yellow, red, blue, black, green]).
% tile(77, [red, yellow, green, black, blue, white]).

% re-jigged a bit
tile(11, [white, black, red, green, blue, yellow]).
tile(22, [white, black, yellow, green, blue, red]).
tile(33, [white, blue, green, yellow, black, red]).
tile(44, [white, green, blue, black, yellow, red]).
tile(55, [white, red, blue, black, yellow, green]).
tile(66, [white, red, yellow, green, black, blue]).
tile(77, [white, yellow, red, blue, black, green]).

%% only six rotations allowed


%% rotate(List1, NStepsAntiClockwise, List2). 

rotate(Cs, 0, Cs).
rotate([A,B,C,D,E,F], 1, [B,C,D,E,F,A]).
rotate([A,B,C,D,E,F], 2, [C,D,E,F,A,B]).
rotate([A,B,C,D,E,F], 3, [D,E,F,A,B,C]).
rotate([A,B,C,D,E,F], 4, [E,F,A,B,C,D]).
rotate([A,B,C,D,E,F], 5, [F,A,B,C,D,E]).

%% colour(Name, Rotation, Position, Colour).

colour(N, R, P, C):-
    tile(N, Cs),
    X is (P + R) mod 6,
    nth0(X, Cs, C).

same_colour(N1, R1, P1, N2, R2, P2):-
    colour(N1, R1, P1, C),
    colour(N2, R2, P2, C).

solve(N1, R1, N2, R2, N3, R3, N4, R4, N5, R5, N6, R6, N7, R7):-
    all_different([N1, N2, N3, N4, N5, N6, N7]),

    same_colour(N1, R1, 3, N2, R2, 0),
    same_colour(N1, R1, 4, N4, R4, 1),
    same_colour(N1, R1, 5, N3, R3, 2),
    same_colour(N2, R2, 4, N5, R5, 1),
    same_colour(N2, R2, 5, N4, R4, 2),
    same_colour(N3, R3, 3, N4, R4, 0),
    same_colour(N3, R3, 4, N6, R6, 1),
    same_colour(N4, R4, 3, N5, R5, 0),
    same_colour(N4, R4, 4, N7, R7, 1),
    same_colour(N4, R4, 5, N6, R6, 2),
    same_colour(N5, R5, 5, N7, R7, 2),
    same_colour(N6, R6, 3, N7, R7, 0).

show(N, R):-
    tile(N, Cs),
    rotate(Cs, R, Rs),
    format("~d    ~w~n", [N, Rs]).

    solve(N1, R1, N2, R2, N3, R3, N4, R4, N5, R5, N6, R6, N7, R7),
    show(N1, R1),
    show(N2, R2),
    show(N3, R3),
    show(N4, R4),
    show(N5, R5),
    show(N6, R6),
    show(N7, R7).

Sergii Dymchenko recently posted a blog showing how a “greater than” sudoku can be solved with constraint logic programming and ECLiPSe CLP.

Sergii’s post inspired me to do the same for answer setprogramming, with clasp/gringo. I’ve uploaded the code to github.

Brief notes on ASP (& Sudoku)

I am just getting started with answer set prolog. Here are some first impressions:

Syntactically, it is very similar to Good Old Fashioned Prolog, with one or two additions. For example:

syntactic sugar

There’s a lot of sugar enabling concise code. e.g.,


expands to


headless predicates

A predicate without a head is known as a constraint. The sense is that the specified conjunction is not true.

:- paint(R, C1, N), paint(R, C2, N), C1 != C2.

In the sudoku code, paint/3 is a fact signifying that a cell at Row and Column has Number. The constraint above states that in a given row, a number can be at most one column.

multi-headed predicates

There seem to be various kinds of multi-headed predicates, with accompanying sugar for concise representation. A common construct is

1 { paint(R, C, P) : number(P) } 1 :- square(R, C).

The part of the head inside brackets is like a set comprehension and expands to

paint(R, C, 1) | paint(R, C, 2) | ... | paint(R, C, 8) | paint(R, C, 9).

Having this kind of disjunction in the head gives a kind of indeterminism: this disjunction is true if the body of the predicate is true.

The numbers to either side of the brackets put lower and upper bounds on the number of facts that this disjunction can introduce. So, in plain English, this predicate says something like “every square should be given exactly one number”.


Semantically there is a difference too. We understand an answer set prolog program as representing a set of states of affairs, where a state of affairs is a set of true facts (i.e., including no facts of the form ‘not P’).

Things like how many states of affairs, and which facts from each state of affairs, are reported to the user are dealt with by declarations (like #show in the sudoku script) and command line arguments.

In practice, this means that instead of passing round a data structure between predicates (e.g., a list of lists for a sudoku grid), statements inside predicates can be made which directly affect the database (i.e., the state of affairs) — e.g., the paint/3 statements scattered about sudoku.lp.

Describing it just now, that sounds scarily like global variables.

Extras for “Greater Than”

As a “Greater Than” Sudoku is just an ordinary sudoku with an extra constraint, I’ve put the required extra predicate lessEqual/4 in a separate script, sudoku_extra_gt.lp

The question grid is just the set of facts that we have initially. With standard sudoku, it’s the cell that have been given numbers, e.g., puzzle_easy.lp:

paint(1, 1, 7).
paint(1, 3, 3).
paint(1, 5, 8).
paint(1, 8, 1).
paint(2, 5, 6).
paint(3, 1, 6).
% ...

QUESTION FOR ASP EXPERTS: at first I tried “positive” constraints with a greaterThan/4 predicate, like this

% ...

but these seemed to be ignored in the answer set. Why? How should I have phrased it?

Running the solver on this Greater Than sudoku shows the paint predicates which are true given all the constraints:

$ clingo 0 puzzle_gt.lp sudoku.lp sudoku_extra_gt.lp
clingo version 4.4.0
Reading from puzzle_gt.lp ...
Answer: 1
paint(8,1,1) paint(2,2,1) paint(6,3,1) paint(5,4,1) paint(9,5,1) paint(3,6,1)
paint(4,7,1) paint(7,8,1) paint(1,9,1) paint(3,1,2) paint(6,2,2) paint(8,3,2)
paint(2,4,2) paint(4,5,2) paint(7,6,2) paint(1,7,2) paint(5,8,2) paint(9,9,2)
paint(6,1,3) paint(1,2,3) paint(7,3,3) paint(4,4,3) paint(2,5,3) paint(8,6,3)
paint(9,7,3) paint(3,8,3) paint(5,9,3) paint(5,1,4) paint(7,2,4) paint(1,3,4)
paint(3,4,4) paint(6,5,4) paint(9,6,4) paint(8,7,4) paint(4,8,4) paint(2,9,4)
paint(9,1,5) paint(4,2,5) paint(2,3,5) paint(7,4,5) paint(3,5,5) paint(5,6,5)
paint(6,7,5) paint(1,8,5) paint(8,9,5) paint(4,1,6) paint(8,2,6) paint(3,3,6)
paint(9,4,6) paint(1,5,6) paint(6,6,6) paint(5,7,6) paint(2,8,6) paint(7,9,6)
paint(7,1,7) paint(3,2,7) paint(4,3,7) paint(8,4,7) paint(5,5,7) paint(1,6,7)
paint(2,7,7) paint(9,8,7) paint(6,9,7) paint(1,1,8) paint(5,2,8) paint(9,3,8)
paint(6,4,8) paint(7,5,8) paint(2,6,8) paint(3,7,8) paint(8,8,8) paint(4,9,8)
paint(2,1,9) paint(9,2,9) paint(5,3,9) paint(1,4,9) paint(8,5,9) paint(4,6,9)
paint(7,7,9) paint(6,8,9) paint(3,9,9)

Models : 1
Calls : 1
Time : 20.837s (Solving: 17.59s 1st Model: 17.45s Unsat: 0.14s)
CPU Time : 20.836s

Open-Source Speech Recognition Toolkits

Tuesday, 26th August, 2014

Here’s a list of FOSS and FOSS-ish ASR toolkits: url, license and rough activity dates, and maybe the odd comment.

Apart from Sphinx4, which is written in The Java Programming Language, all of these are written in C/C++.

Kaldi looks the most interesting and mature. I’d also like to have more of a look at Bavieca, GMTK and TLK.

Have I missed any?

  • Bavieca
    Apache 2.0

  • GMTK
    Open Software License v. 3.0

  • HTK
    Weird license:

    Latest version is 3.4.1, 2009

  • iAtros

    unclear documentation
    unclear if HTK required
    designed for recognition of speech and handwriting

  • Kaldi
    Apache 2.0
    Current (last sf update 2014-08-11)

  • RASR
    Non-commercial use only

    Non-Commercial Use Only

    Free for non-commercial use only; commercial license request & pay

  • Sphinx
    Sphinx4 (java) is current
    Sphinx3 (C/C++) is unmaintained

  • TLK
    Apache 2.0
    2013 & current


Get every new post delivered to your Inbox.