First off, I’d ask your pardon for the lull in postings - this spring has been insane. It has been very much fun - traveling the world, talking about my research and meeting people I only knew electronically - and also very intense.
To break the lull, I thought I’d try to pick up what I did last summer: parallel computing on clusters. It’s been a bit of blog chatter about SAGE and how SAGE suddenly has transformed from a Really Good Idea to something that starts to corner out most other systems in usability and flexibility.
Matlab? SciPy bundled with SAGE and the Python integration seems to be at least as good, if not better.
Maple? Mathematica? Maxima? Singular? GAP? SAGE interfaces with all those that it doesn’t emulate.
I saw the Cerebrate solve the first Scripting Games challenge: Pairing off. And immediately thought “I can do that in Haskell too”.
So, here it is.
import Data.List
cards = [(1,7),(0,5),(3,7),(2,7),(2,13)]
countpairs [] = 0
countpairs [a] = 0
countpairs (a:as) = length . filter (((snd a)==) . snd) $ as
pairingOff = sum . map countpairs . tails
And that’s that. Alas, the actual competition only takes Perl, VBScript and PowerShell, so I won’t be submitting this.
Brent Yorgey wrote a post on using category theory to formalize patch theory. In the middle of it, he talks about the need to commute a patch to the end of a patch series, in order to apply a patch undoing it. He suggests a necessary condition to do this is that, given patches P and Q, we need to be able to find patches Q’ and P’ such that PQ=Q’P', and preferably such that Q’ and P’ capture some of the info in P and Q.
However, as such, this is not enough to solve the issue. For one thing, we can set Q’=P and P’=Q, and things are the way he asks for.
Now, I wonder whether we can solve this by using PROPs (or possibly di-operads or something like that). Let’s represent a document as a list of some sort of tokens. We’ll set
the set of all lists of length
, and we’ll set
to denote operations that take a list of length n and returns a list of length m.
Last week, the news hit the blogosphere that Google had released a beta API for generating graphs using a reasonably easy and transparent GET parametrisation.
Inspired by this, and inspired by my early playing around with Ruby on Rails, I decided to whack together a Rails plugin that takes care of building the Google Charts IMG tag using what I hope is reasonably easy to use syntax.
I have a test-site using random data up for playing around with it.
The test-site as such runs on Ruby on Rails. The controller does some parsing and setting up of relevant arrays, and primarily generates random data for plotting.
The view has the following source code:
<p><% form_tag "" do %>
<label for="options[type]">Type</label>
<%= select_tag "options[type]", options_for_select(@typeopts,@options["type"])
%>
<label for="options[title]">Title</label>
<%= text_field_tag "options[title]", @options["title"] %>
So, there is this one big and neat framework called Rails, building on top of this one neat new programming language called Ruby.
And one of the things that makes Rails so Damn Neat is that if you only set things up the right way around, it guesses almost everything you need it to guess for you.
One of the ways it does this is by pluralization. Basically, the model Foo has a model defined in app/model/foo.rb and it accesses the database table foos.
So, when talking a good friend through the basics, we created the table persons and generated the model Person. And promptly got an error from the framework.
It turns out that the pluralization of person is people. I wonder what else irregularities they built into the system. If I have a model called Index, does Rails expect it to read from the database table indexes or from indices?
dynkin:~/magma> magma Magma V2.14-D250907 Wed Sep 26 2007 13:19:51 on dynkin [Seed = 1] Type ? for help. Type-D to quit. Loading startup file “/home/mik/.magmarc” > Attach(”homotopy.m”); > Attach(”assoc.m”); > Aoo := ConstructAooRecord(DihedralGroup(4),10); > S := CohomologyRingQuotient(Aoo`R); > CalculateHighProduct(Aoo,[x,y,x,y]); z > exit; Total time: 203.039 seconds, Total memory usage: 146.18MB
And this is one major reason for the lack of updates recently.
IMPORTANT: Note that the implementation herein is severely flawed. Do not use this.
One subject I spent a lot of time thinking about this spring was taking tensor products of A∞-algebras. This turns out to actually already being solved - having a very combinatorial and pretty neat solution.
Recall that we can describe ways to associate operations and homotopy of associators by a sequence of polyhedra Kn, n=2,3,.., called the associahedra. An A∞-algebra can be defined as being a map from the cellular chains on the Associahedra to n-ary endomorphisms of a graded vector space.
If this was incomprehensible to you, no matter for this post. The essence is that by figuring out how to deal with these polyhedra, we can figure out how to deal with A∞-algebras.
Syntaxfree writes over at his blog about a silly little toy he wrote, using the PFP library, to generate random text.
Now, his text is unreadable. I mean, it’s even unpronounceable. Why? Because he’s looking at bigram distributions of letter.
Great, I thought, I’ll do him one better. Random text using bigram distributions on words must surely be a LOT better than random text using bigram distributions on letters. At least the words come out readable, and they may even come out in a decent order.
So I sat down with his code, and hacked, tweaked, and monadized it to this
Inspired by other bloggers on Planet Haskell, I thought I’d just sit down and write a retrospection post, reviewing the past year - primarily from angles such as mathematics, computers and my generic life situation.
It divides neatly into two different sections: the months as a commercial programmer and the months as PhD student and academic careerist.
The year began still working for Teleca Systems, and with security consulting for Stockholm-based firms and frequent trips back home.
Then as the year went on and my PhD applications grew more and more, I started getting results. I got invited to Bonn for an interview with the Homology and Homotopy graduate school program - which was in the end turned down because I was more of a homological algebraist than a topologist. And the week after that, I was invited to Jena for an interview for a position doing PhD work on computational homological algebra. The interview went well, the potential advisor was nice (and a once-roleplaying gamer to sweeten the deal more) and I got the position just a few days later.
In a recent post, pozorvlak reminded me of one of the reason it is important to have a good, obvious, and quick-to-write programming language around.
He, as I, is a mathematician, spending his time thinking, finding patterns, and trying to formulate (more or less) absolute proof that his patterns hold all the time, alternatively ways to demonstrate that they may not be universal.
In the post linked above, he starts by a neat little exercise, gets interested, and goes out to look at more examples. These show a very clear pattern, and after following this pattern quite some way out, he finally believes the pattern enough to start searching for a proof: which he also finds.
This term, I’m listening to a lecture course on Computational Group Theory. As a good exercise, I plan to implement everything we talk about as Haskell functions as well.
The first lecture was mainly an introduction to the area, ending with a very naïve algorithm to generate a permutation group from a set of generators. Next week will bring less naïve algorithms with not quite as horrible complexity.
Before the algorithm can be brought, we’d want some undergrowth: we’d want to be able to work with permutations at all. So, we’ll start with the basic group theory and permutation implementations. A lot of this is stolen or rewritten from this permutation group code.
Our code will make use of two libraries, so if you collate code snippets while reading this, you’ll want to use
If you don’t want to bother with that, the code is available here.
As we left off the last installment, we were just about capable to open up a window, and draw some basic things in it by giving coordinate lists to the command renderPrimitive. The programs we built suffered under a couple of very infringing and ugly restraints when we wrote them - for one, they weren’t really very modularized. The code would have been much clearer had we farmed out important subtasks on other modules. For another, we never even considered the fact that some manipulations would not necessarily be good to do on the entire picture.
To deal with the first problem, let’s break apart our program a little bit, forming several more or less independent code files linked together to form a whole.
First off, HelloWorld.hs - containing a very generic program skeleton. We will use our module Bindings to setup everything else we might need, and tie them to the callbacks.
Since the content rate of haskell-related posts is going up, the feed of this blog will get added to Planet Haskell. Hi, Planet!
After having failed following the googled tutorial in HOpenGL programming, I thought I’d write down the steps I actually can get to work in a tutorial-like fashion. It may be a good idea to read this in parallell to the tutorial linked, since Panitz actually brings a lot of good explanations, even though his syntax isn’t up to speed with the latest HOpenGL at all points.
First of all, we’ll want to load the OpenGL libraries, throw up a window, and generally get to grips with what needs to be done to get a program running at all.
main = do
(progname, _) <- getArgsAndInitialize
createWindow "Hello World"
mainLoop
This code throws up a window, with a given title. Nothing more happens, though. This is the skeleton that we’ll be building on to. Save it to HelloWorld.hs and compile it by running
ghc -package GLUT HelloWorld.hs -o HelloWorld
The weekly reports have been dead for a while. Reason? The blog has been dead for a while.
The old computer running this website had some problem all of a sudden about 3 weeks ago. These problems appeared as a complete lockdown of the system - no response to anything. So my brother - with me on the other side of a telephone, tried to reboot the box; but couldn’t get it back up online again. He was headed out to a LARP anyway within hours - and so couldn’t really do much more about it.
Right.
End result? I joined forces with a good friend of mine; we split hardware costs for a slick new box - an Asus barebone box with a 64bit processor and a gig of RAM. It received the harddrive and network interface from the old box, and was with that good to go - only .. processor architecture changed; and so for optimal performance, it’d be a nice idea to actually use a new system install that took advantage of the extra available bitwidth.
Todays webbrowsing led me to John Baez finds in mathematical physics for week 226, which led me to snoop around John Baez homepage, which in turn led me to stumble across the Geometry of Computation school and conference in Marseilles right now.
This, in turn, leads to several different themes for me to discuss.
In the weeks finds, John Baez comes up to speed with the cryptographic community on the broken state of SHA-1 and MD-5. Now, this is a drama that has been developing with quite some speed during the last 1-1½ years. It all began heating up seriously early 2005 when Wang, Yin and Yu presented a paper detailing a serious attack against SHA-1. Since then, more and more tangible evidence for the inadvisability of MD-5 and upcoming problems with SHA-1 have arrived - such as several example objects with different contents and identical MD-5 hashes: postscript documents (Letter of Recommendation and Access right granting), X.509 certificates et.c.
Stumbling across the blog Epsilon-Delta with a brilliant article series on mathematics as key to effective programming. This in itself merits a closer look at the blog; which in turn merits it a place in my blogroll. Go and read it you too!