Years ago, when I was writing the code to support my thesis, our research group was using the functional programming language SML-NJ. As the saying goes, it's pretty indy, you might not have heard of it. You can view SML-NJ as a early ancestor of Haskell, but without the rich ecosystem of Monadic tutorials and proselytizers. Our CS colleagues were very enthusiastic about the language, and rightly so: compared to, say, Java, functional languages offered (and continue to offer) a tantalizing reward of automagic parallelization. As a non-negligible bonus, SML-NJ was (and probably still is) a completely green field. There were no public available libraries as far as I knew, meaning the CS guys could start at year zero and code with purity. They began with monoids and worked their way up to vector spaces, matrices, and so on. These libraries were very elegant. Because of the close binding of math and code, they were 'obviously' correct by inspection.

My meshing code needed the user (just me, really) to enter line segments and facets which should be respected by the mesh. It became apparent that asking the user (again, just me) to enter the equations defining these was too onerous. The code should just compute the equations when given the locations of points known to be in these features. The best way to do this, I reasoned, was via a singular value decomposition: find the dimensions which explain the most variation in the coordinates of the points.

Without any extant packages in SML/NJ, I set out to write the SVD code myself. I spent two days holed up in my office with a copy of Golub & Van Loan's book. This is 'the' book for guiding you through this process, or so I reasoned, and I was a mildly competent …

I recently caught the flu double header. As appropriate for someone in my condition, I spent a good many hours riding around on city buses, mumbling to myself and reading about bitcoin on my phone. If you are looking for a decent semi-technical introduction, Michael Nielsen's explanation is recommended.

The part of bitcoin that strikes me as bizarre is what the proof-of-work exercise entails. Essentially, to sustain an agreed-upon but decentralized public record of transactions, participants are madly trying to solve a useless reverse-hashing puzzle. Basically, "guess some bits such that when you append them to this fixed long string of bits, the hash starts with at least 5 (or whatever) zeroes." By making the puzzle hard to solve and easy to verify, and rewarding those who solve it, the system has accountability and resilience, and is robust against takeover.

However, it is hard not to see the hashing puzzle as a satire of contemporary work culture: participants are paid to use their computers to solve numeric puzzles which are of no interest to anyone. (Never mind the potential environmental impact if cryptocurrencies see greater adoption.)

You know who else liked Ansatz?

However, the hashing puzzle reminded me of something, in my feverish state. In the first weeks of differential equations classes, it is customary to pose a differential equation, then present the solution, deus ex machina, and confirm it is the solution. Hard to solve, easy to verify. Partial differential equations have the same nature. For example, the solution to the heat equation involves some drudgery, but confirmation of the solution is pretty simple. In fact, computers can even verify solutions of differential equations because symbolic differentiation is relatively simple.

So what if we could make an altcoin where the proof of work involved the solution to a real-world …

A long time Matlab user, stuck in a marriage of convenience, mumbles in his beer.