A supposedly simple exercise I hope to never repeat
Wed 16 December 2015
by Steven E. Pav
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
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 …
Proof of Useful Work
Sat 12 December 2015
by Steven E. Pav
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
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 …
Why not Matlab
Sat 04 October 2014
by Steven E. Pav
A long time Matlab user, stuck in a marriage of convenience, mumbles in his beer.