Sean's Research

Org-babel for J


As part of my emacs org-mode work flow, I have been using org-babel for a while. This allows you to insert code blocks into org buffers and have those blocks be executed when your file is compiled. This is a really handy method for doing reproduceable research. For example, you can call the source code function in R to do the statistical calculations for data in a table. If the data in the table changes, so will the calculation of the output data change. This prevents the perennial problem of having data in one file (typically a spreadsheet) and not knowing whether the document you generated for a paper used the 12th of September or the 15th of September version of the spreadsheet. By having explicit links to data and to the algorithm that manipulates that data, you can explicitly record the calculations you used to produce your data. And so can anyone else if they want to. This is very important for producing believeable data.

Org-babel is built into emacs org-mode, and supports an amazing array of programming languages, from compiled languages like C to interpreted languages like python or MATLAB, to specialised scripting languages like awk or gnuplot.

The best feature for me is that org-mode can read from or write to org tables, allowing a seamless integration between code and document. However, this capability differs between programming languages. Some languages, like python and common lisp, seem to be very well catered for in this regard. However my favourite programming language, J, is rather less well catered for. In particular, there does not seem to be a built-in way to pass variables to and from the code block. Instead, you can run your code as if it were a script, and the source block will provide the last calculated value as an output. For example,

#+BEGIN_SRC j :exports both
 NB. The square root of the sum of the squares of the numbers
 NB. between 1 and 10
	    [a =: %: +/ *: 1 + i.10
: 19.6214

The output, as stated by the comment, produces the Euclidean norm of the integers between 1 and 10 inclusive, which is 19.6214, and displays it as the result from evaluating the source block. However, for other programming languages one could supply a variable argument using the :var command in the header, to pass a variable argument to a function. So, for example, the 10 in the example above could be replaced by each of the values in the column of a table.

Like most things in emacs, the code for executing commands in code blocks is available as elisp. So, in theory, it should be possible to modify the existing elisp export code to pass variables, including rows and columns in tables, to a J function. At the moment though, my understanding of elisp is not sufficiently good to be able to work out how to do this, but it sounds like a very useful thing to do, and necessary if J is to be seriously used from within org-mode. If anyone has managed to do this, I’d be very interested to know how it’s done. If not, I’ll need to learn some more elisp and try to reverse engineer how it’s already been done for MATLAB code to see if I can do something equivalent for J.

Oh, and happy new year for 2021. I wanted to get one more blog entry done before the end of 2020, as an old-year’s resolution…

Reminiscences on programming


I’ve just been thinking: programming computers has been a big part of my life ever since I was a child.  The first computer I ever got to touch was a microbee computer in year 7.  Before that I had seen some Atari 400s in Myer, and a TRS-80 at Tandy Electronics (Australia’s version of Radio Shack), but I was not allowed to play on them. Microbees were an Australian-made computer built specifically for the education market.  For some reason our school had two of these.  We were allowed to use some kind of word processor on it, but nobody at school seemed to know what to do with it.  I don’t remember much about it other than using it made me want a computer.  At around the same time as I was using the microbee at school, my father took early retirement from his job on the waterfront and we moved from Western Sydney to a very small town.  I was about 12.    My parents had never had much money, but they were keen on my education, and I was most likely constantly banging on about computers so one day to my amazement my Dad put down the unthinkable amount of $950 on a Commodore 64 with disk drive and 1 floppy disk, and a programmer’s reference guide and we walked out of the store with it.  I guess that once we had brought the (relatively inexpensive) house he had one shot at buying something for each of us:  Mum got an olive-green IBM Selectric typewriter, Dad got an air conditioner and a monstrous Kreisler TV with roll-out wooden doors and I got the Commodore.  Then we were poor again!

I would set the computer up in front of the big TV and spend hours with it and the programmer’s reference guide.  My father refused to buy games (having spent so much on the machine) so any games were going to have to be made by me.  My limit on the computer was around 4 hours sitting cross-legged on the floor until I would lose all feeling in my legs or Dad would make me do some outside work (the house was a fixer-upper).  I had no idea what I was doing, but I read everything I could.  During those times nothing else mattered to me.  I learned to program in BASIC, and read all the copies of Byte Magazine and Creative Computing trying (usually without success) to make the type-in basic programs work.  On the odd occasions I’d save up to purchase Australian Personal Computer or one of the many British Commodore magazines to find out more about programming.  But my town was no silicon valley, and there was no internet.  The only person I knew who knew how computers worked was the Hungarian TV repair man, who had to come in to fix a problem with Dad’s pride and joy (which I’m sure he thought my computer was responsible for creating…).  This fellow explained to me how flip-flops worked, which was to me like learning the mysteries of some secret society.

At my school we also had computers: Apple II/es in the maths department and a 32 kB BBC micro in the library.  Again, nobody seemed to know what to do with them, but I was happy to fill the void.  I think I was the only student who ever got to use the BBC micro.  It was hooked up to a Telstra-run bulletin board service called VIATEL, if I remember correctly, which was a very primitive text-based centrally served prototype for the internet.  You could check the weather, share prices and other things.  I didn’t get much of a chance to look at it, though, because they charged about 10 cents per page of text downloaded, and in the first day of playing with it, I managed to rack up a bill of around $65 in about an hour.  Before I had another chance to check my portfolio and play online poker I got called into the Vice Principal’s office and it was explained to me that I would no longer be using that computer…

We kept using the Apples, which were really nice machines.  Very sturdy construction, but only 8 colours on the display, compared to the amazing graphics and sound capability of the Commodore at home.  The sprite graphics were great.  I remember trying to program graphics on the Apple but getting nowhere.  I didn’t understand about things like memory mapping that would have really helped.  There was one older kid at the school (by the last name of Ward) who would make graphics of a sort by using lots of print statements strung together to make eg a car race track scroll down the page.  We looked down on these  ‘Wardy graphics’ programs as primitive, but at least he was able to make things that looked like animations, and he put so much time into it.

On the C64 you were limited to BASIC, although I knew that assembly language or a compiler was what all the professional programmers used.  But that stuff was certainly not readily available to me.  I think I will take to my grave the knowledge that POKE 53281,0 turned the background from the default blue to black, and that putting different numbers using the POKE command at location 53280 would do the same for the screen border.

Then one fateful day in 1985 I found a cartridge in the K-mart Albury bargain bin.  It was HES Forth, an implementation of the Forth programming language for the C-64.  Not only was it a much better language than Commodore basic, with a built-in line editor, but it also had a (somewhat unusual) assembler, so that now I could finally take full advantage of a computer by converting code to machine language!  I didn’t accomplish a lot, but I learnt a lot about computers and the Forth language paradigm.  In fact, I still use that language when teaching microcontroller-based instrumentation.    I remember trying to decipher the terse user manual with all its assumed knowledge, and trying to reverse engineer a prime number generating program that they included as a demo.  That really flicked a switch somewhere in my head and programming has varied somewhere between an obsession and an interest ever since.

The line editor from HES Forth for the c64

All the programming since has been trying to recreate the thrill of making a computer do something I want it to do, delighting in working out some trick to use the computer to model something.  In hindsight I’m glad my Dad refused to buy me any games, though some of those Infocom titles did look pretty sweet at the time.  Instead I got hooked on a pastime I still get great pleasure from some 35 years later.

Over the next indefinite period when I can find the time, I’ll write up a little programming project I’ve started to model the Direct Simulation Monte Carlo method for simulating rarefied flows, using my current favourite programming language: J.  I’ll try to split the task into little parts and explain what I’m doing at each step, in case the 13-year-old version of me is listening.  I guess that’s what made me think of writing this post.