Conjecture Threshold

Today at his blog, Peter Woit responded to some rebuke or other from the stringeratti cabal on his disrespect for their sacred creed and its inevitable ascendance. He's got a severe commenting policy there and I don't begrudge it. I can imagine someone with his votive alert for bullshit borne out of disgust of general delusion as an ecclesiastical order coopts fundamental physics in a way everyone loves to compare to the celebrated hubris that was shattered 113 years ago--I can imagine someone in his position carefully inscribing himself from the ruling academic class with an appreciable buffer that protects comments as well.

But this is my blog and, waxing bold in my own sovereign licensure, I have neither professional apprehension towards the high court of ivy strangled decorum nor reverence for an ostensible ranking of living minds and I grant myself permanent freedom to post whatever I fancy. The following comment was deemed inappropriate for the curated safe comment space on the blog itself:

If we're now in the business of measuring and comparing the 'intelligence' housed in discrete human instances, I'd say that Woit's smarter than any of those anointed to ascend into the high ivory tower incapable of discerning that the multiverse has no clothes, despite whatever whizbang smoke and mirrors they're able to conjure in its favor.

If this comment seems gratuitously homenim, it's because I err towards frustration with the status quo keepers of the theoretical enterprises in fundamental physics rather than wanting or not to construct Woit paean.

Print all iptables rules

It is unfortunate that iptables does not have a simple builtin option that does this, as I'm too impatient to type out this loop every time I need to see what's really going on. I'm for sure too impatient to type out 5 parallel commands. The -S option does not give the same useful formatting as -L and no option can be combined with -vL to request the rules from all tables. I may just have to add this to my shell init.

for table in filter nat mangle raw security ; do printf "\n=====%s=====\n" $table ; sudo iptables -vL -t $table ; done

Bow Technique


Many years ago I watched an excellent documentary about violinists in which Itzhak Perlman likened the violinist's bow to an "artist's paintbrush", describing how each requires "a lifetime to master". Likewise, I have personal second hand anecdotes from Pinchas Zukerman saying things like the symphonic orchestra is the greatest of all instruments, and that when someone asks you what you play, you should respond that you "play the bow".

From my 24 years of viola playing, I can substantiate these two metaphorical idioms about the bow with my own vicissitudes of the bow kind.


But first let's discuss the more significant differences between violins and violas. Violins are almost ridiculously small. Every time I pick one up and play it, it feels as if I'm holding a toy. But thus compared to the viola this toy holds two very important advantages:

  • Being smaller means that I can practically dominate the entire fingerboard from 1st position, or if necessary shift up into 13th position without any care or effort.
  • The smaller size means that the response time (the time between initiating bow movement and the instrument achieving steady-state resonance), at least for a well-made violin, is vanishingly small. A skilled player can move from ethereal to furious to euphoric to bucolic instantaneously and all in the same phrase, even.

Going back to the viola, you realize how comparatively unwieldy is its size and acoustical-mechanic hysteresis. Both imply a small, but appreciable effort for each action or style change. Playing a note on the viola requires you to make micro adjustments in the left hand finger position, angle, and pressure to be followed by the highest care in placing the bow relative to the string, adjusting the hair angle, finding the correct contact point along the string relative to the bridge and along the bow relative to the center of mass, and then calculating the perfect shape of bow attack and drawing the bow fluidly across the string using the correct bow speed and arm weight. This is all in addition to the interrelated two dozen posture and form techniques that must be mastered before any serious study of the instrument is begun.

Even the strings on a viola being longer means that micro adjustments to left hand position for intonation are larger, slower, and more difficult, and the strings being more widely spaced makes each string crossing that much more treacherous. Every instrument has a joke about how it's not played in tune. The viola variation of this idea seems to be something like "always being tuned, but never being played in tune". Only a violist is really going to understand what this means as it grossly controverts the multitude of diligence in simultaneous skill required to produce any note at all on top of what you would already baseline expect for a violin.

Good players and instruments will naturally have easier times overcoming and mitigating these challenges. For example, the most expensive viola I have ever tried (German, 1880s': $163k) had by far the shortest response time I've ever experienced.

It's the Bow that Chooses the Instrument

Now that we've gotten the violists' apologetica out of the way, let's talk about bows.

One more anecdote: The late and beloved Peter Prier, proprietor of one of the first, if not the first, violin making school in the Western Hemisphere, described the relationship between the instrument and the bow as a "marriage". For many years, my only instrument was a student viola my parents got me in high school and it was a chore to play on. About its only quality of redemption was that it looked well enough. I was finally able to afford a real instrument only a year ago. Buying a bowed instrument is a two part process, not only because bow making is its own trade, but also because a caring and attentive musician must seek a proper mate for their instrument. I was able to find a matching bow in about 2 months. The experience was like the finding of a wand a nascent wizards as he embarks on a lifetime of devotion to the craft must have had. It was not the most expensive bow I tried, but in ways that still mystify and enchant me, upon picking it up, it seemed to feel light and warm in my hand, the sun shone a little brighter and the birds outside sang a little sweeter and the colors of the world were a little deeper and no sight or object went untinctured from an ubiquitous, subtle beauty. It drew out of my viola clarity and focus while enhancing the instrument's intrinsic warmth and brilliance. When I stopped, my face was hot, my muse quickened, and I knew I had found The One. Going back to my student bow was like trying to bow with a hack saw. Analogously, I tried the same two bows on my old instrument with almost no perceptible difference.

From Good to Great

This analogy of instruments and bows leads to my next point, which is that the difference between a good student and a great master is both big and small, or rather, that the making of great music is all done in the minutiae: small quantifiable differences in wood quality and craftsmanship, kinesthetic control, aural feedback, and sense. One may measure these differences with crude tools and conclude with the expected small discrepancies, but that is because the profound differences are much smaller still. A great master has control over the tonal center down to the last overtone beat fraction, vibrato to like the 19th term in Fourier decomposition, and most of all, the bow inflection down to the last neuron in her hand.

There is a temptation, especially in orchestral string sections to over-prize these minutiae from the unified symphonic narrative and copiously or fastidiously annotate the written music, like a lawyer unseemily burdening banalities with confounding boilerplate. Any musician can tell you that excessive annotation encumbering the page, even if it does not obscure the notes themselves, will distract enough to make the copy seem unbearably unreadable. Similarly, a preoccupation with bowings is frustrating when it means the whole section has to rebow parts of the music right up until the dress rehearsal. There really is no perfect bowing, and a corollary of this is that a good musician can make almost any bowing work. I have seen some really funky bowings in my time, but none of them compare to the distraction of rebowing a part mid-rehearsal or of the value of the lost rehearsal time. It is true that minutiae are what matter, but once you cross the threshold of ephemera, your part annotations are going necessarily change every time you play the music and you music will be be that much less intelligible. Because making music is also wonderfully spontaneous and an intimate, transcendental collaboration of sound among peers, most of which is better left as a subtext.

The Real Heifetz

This is what I really wanted to talk about before getting distracted with my own anecdotes and contexts. I have once heard that playing "faster and cleaner than Heifetz" has been achieved in one historical or famous circumstance or other. It is true that Heifetz developed a style that allowed him to play famously fast, but if speed is what you desire, you might be better off with Hahn or if you want cleanliness, try Perlman (Note: Hahn and Perlman in their own ways are both magnificent masters of the violin). I've always thought the notion bizarre because these are not the greatest virtues of a Heifetz recording. They may be part of the necessity, but the sufficiency of the art is largely accomplished by, again, the minutiae. One does not simply agitate the bow as rapidly as possible across the strings. Rather the delectable joy of Heifetz's sound is its vintage passion and collimated fury. One listens to Heifetz to expand one's soul.

HowTo Get a Site's Certificate Fingerprint

I finally got around to setting up TLS to the IRC servers that I use. It is incredible that this is not default or that there does not even seem to be conventional ports. Freenode suggests 6697, 7000, and 7070, but there is an independent draft standard for 6697.

Another server I connect to is protected by a wildcard domain certificate, but WeeChat did not want to verify the certificate:

09:09:28 xmission  -- | irc: reconnecting to server...
09:09:28 xmission  -- | irc: connecting to server (SSL)...
09:09:28 xmission  -- | gnutls: connected using 2048-bit Diffie-Hellman shared secret exchange
09:09:28 xmission  -- | gnutls: receiving 1 certificate
09:09:28 xmission  -- |  - certificate[1] info:
09:09:28 xmission  -- |    - subject `CN=*,O=XMission Networks
09:09:28 xmission  -- |      LLC,L=Salt Lake City,ST=Utah,C=US', issuer
09:09:28 xmission  -- |      `CN=DigiCert SHA2 Secure Server CA,O=DigiCert
09:09:28 xmission  -- |      Inc,C=US', serial
09:09:28 xmission  -- |      0x081a17d0d17cfe5abd82f38b2396070e, RSA key
09:09:28 xmission  -- |      2048 bits, signed using RSA-SHA256, activated
09:09:28 xmission  -- |      `2016-02-09 00:00:00 UTC', expires `2019-04-12
09:09:28 xmission  -- |      12:00:00 UTC', key-ID
09:09:28 xmission  -- |      `sha256:a9fbe66d6490806d4c827c9a22f63c3985ffc689af85c737d060458f605b121d'
09:09:28 xmission =!= | gnutls: peer's certificate is NOT trusted
09:09:28 xmission =!= | gnutls: peer's certificate issuer is unknown
09:09:28 xmission =!= | irc: TLS handshake failed
09:09:28 xmission =!= | irc: error: Error in the certificate.

I'm not particularly interested in why the CA certificate bundle that ships with openssl or certifi (mozilla) (both of which I tried) do not automagically enable all the encryptions for this domain since I was able to find an easy workaround for my use case. The workaround involves downloading the certificate and extracting the fingerprint.

$ PORT=6697
$ echo -n | openssl s_client -connect $SERVER:$PORT 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -noout -fingerprint -sha256
SHA256 Fingerprint=D9:47:5E:E4:69:24:09:7D:57:B9:5A:A1:2F:B6:3D:94:C5:19:A2:85:46:47:F8:02:3B:24:DF:0A:87:08:33:C9

WeeChat needs the fingerprint without the delimiters (:) at the byte boundaries, so (I'm sure the multiple sed and openssl commands could be factored but that's ostensibly too much effort for the present need):

$ echo -n | openssl s_client -connect $SERVER:$PORT 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -noout -fingerprint -sha256 | sed 's/SHA256 Fingerprint=//' | sed 's/://g'

Now, if you randomly happen to have the exact same problem that triggered this descent of inquiry as I, execute the following commands in WeeChat:

/set irc.server.xmission.address
/set irc.server.xmission.ssl on
/set irc.server.xmission.ssl_fingerprint D9475EE46924097D57B95AA12FB63D94C519A2854647F8023B24DF0A870833C9
/reconnect xmission
13:02:10 xmission  -- | irc: disconnected from server
13:02:10 xmission  -- | irc: connecting to server (SSL)...
13:02:10 xmission  -- | gnutls: connected using 2048-bit Diffie-Hellman shared secret exchange
13:02:10 xmission  -- | gnutls: receiving 1 certificate
13:02:10 xmission  -- |  - certificate[1] info:
13:02:10 xmission  -- |    - subject `CN=*,O=XMission Networks
13:02:10 xmission  -- |      LLC,L=Salt Lake City,ST=Utah,C=US', issuer
13:02:10 xmission  -- |      `CN=DigiCert SHA2 Secure Server CA,O=DigiCert
13:02:10 xmission  -- |      Inc,C=US', serial
13:02:10 xmission  -- |      0x081a17d0d17cfe5abd82f38b2396070e, RSA key
13:02:10 xmission  -- |      2048 bits, signed using RSA-SHA256, activated
13:02:10 xmission  -- |      `2016-02-09 00:00:00 UTC', expires `2019-04-12
13:02:10 xmission  -- |      12:00:00 UTC', key-ID
13:02:10 xmission  -- |      `sha256:a9fbe66d6490806d4c827c9a22f63c3985ffc689af85c737d060458f605b121d'
13:02:10 xmission  -- | gnutls: certificate fingerprint matches
13:02:10 xmission  -- | irc: connected to (

You will have to verify whether your IRC server respects port 6697 as the TLS port.

Skew Strings


Monday of this week I synthesized a combination of two obvious observations into a pair of aphorisms:

When hacking while wearing a black hat, one must string together a sequence of bugs to do one's 'job'.

When doing anything else in life, one's job must be done by stringing together a sequence of bug workarounds.


Ordinarily you would expect this sort of thing to be posted to a trendy proprietary platform that purports to peddle truncated, dubious drivel such as this in a charade of public commons. But then I'd have to bedazzle it with emoji, hashtags, and frustrated urls and who really has time for all that? Perhaps I don't, being thus anachronistic. If so, it is an intellectual compliment, as time as a parameter or a metric is a tool of ignorance, for enlightenment arrives when you know it's only a dimension with the opposite signature: anachrony. Observe the metric tensor:

\begin{equation*} g^{\mu\nu} = \left[ \begin{matrix} 1 & 0 & 0 & 0 \\ 0 & 1 & 0 & 0 \\ 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & -1 \\ \end{matrix} \right] \end{equation*}

(MathJax, w00t!)

I remember the first time someone in my family used the word 'facebook'. After recovering from the initial surprise, I began to realize that pop culture was finally beginning to track geek culture. For over a decade now this has been true and it manifests in everything from 'nerd' protagonists, rather than nerd sidekicks or flat, stock nerd characters, to hipstergrammers cargo culting code in decrepit brick warehouses.

Now that code literacy and science promotion have gone viral in a big way and no royal roads have been discovered, it seems that we may be approaching an evolutionary juncture where futurists will invent some new economy full of professions that make hard engineering and software appear again as the dreary difficulty they always have been. Then I can go back into para-autistic anonymity and be awkward with confidence.


When I was younger, my family decided to gather all of the surface rocks in our back yard into a large hole. However, this was to practice a deception as anyone from Utah can tell you, the purpose of dirt is to fill the spaces between the rocks. Digging a hole is an exercise in rock removal. Shovels are a lie and shouldn't be sold in Utah. With their deep scooping blade, you're made to think digging is a matter of gently sliding the blade into the ground and hefting out luxurious scoops of pure dirt. In reality a digging shovel is going to get you at most 1 cm of depth on the first try. You bend down and spend 5 minutes prying out the rock you've found with your fingers and think, 'great, now I'm ready to do some serious digging' only to be thwarted by the rock that that rock was resting on. After the 19th rock, you begin to realize that it's rocks all the way down and the shovel is no more than a rock finder. This is the same pattern with modern software and the whole glob of the computer infrastructure industry.

AWS or Azure may have a snazzy (if frenetic) UI, but don't expect anything to work as easily as it is advertized. You're better off with a real digging tool, like a pick or a digging bar or an API and a command line. Though less frustrating and more honest, when working at the lower level, more effort is required. You are still going to find rocks (bugs) but you will be better adjusted to process them intelligently and necessarily than otherwise.

Hyperbolic Parallelicity

One of the more successful software development methodologies I have been using can be summarized with the following list:

  • Identify the goal
  • Start as near the goal as is prudent
  • Write the minimal code to get from the start to the goal
  • Attach structure to this minimal case until the feature is sufficient or revise and replicate the minimal case as an atomic motif

If you imagine the multidimensional state space containing the start and goal states, you can easily recognize that there are myriad paths from start to goal. Moreover, the minimal path you've just constructed is very likely within 0.8 of the optimal path regardless of the hoard of rocks menacing the state space. The path you've found neatly edges around the intervening stones with unburdened alacrity and has neither awareness nor care for any other hazards in the space.

Even if the feature requirements impose severe constraints on spacetime complexity, or portability, or you are compelled by existing code to significantly contort the path, starting with this approach will still exact less effort and sanity than fantasy programming a grand opus. The latter's august design, because it is not pathfinding will have its elegance distorted beyond comprehension by unanticipated edits when the time arrives to actually use it. At that point, technical debt is an understatement, or parabole, if you will.

What Can You See: A Guide (Rant) on Commenting

I occasionally find code examples online where the author, in their effort to fully communicate the breadth and detail of a proposition and solution, has commented almost every, or every single line of code.

I am not going to say that exhaustive commentary is universally opprobrious, but as sample code online, for my part, all I can do when I see this is rage close the tab and look elsewhere for examples to help me with my project. I will, however, propose that there is almost no use for the

# comment
# comment

format. The alternation is arresting to the reading of either code or commentary. The only way to get any comprehension out of this maximally irritating and interrupting layout is to slowly read each line sequentially from top to bottom and hope the author's flow of logic is perfect and simple enough to communicate the essential detail you're looking for without rereading. I suppose then this kind of commenting might make sense for beginners (to beginners?), but even then, I wouldn't expect a beginner to learn, or want to learn this way from 100+ lines of code (that is 50+ lines of comment and 50+ lines of code). One of many errors of presentation this style gives away without even reading the code (or the commentary) is that the author can't or doesn't know how to separate information on the structural and conceptual layers in the code. As a result, interspersed amongst all the comments telling you about how variables are getting initialized must go the fragmented discussion about what the code is trying to do. Everything is looked at from the perspective on the street. All you can see looking up are trees and tall buildings. There are cars driving by, but you don't know where they're coming or going, or why. You can't gauge the relative height of the buildings, or the architectural aesthetic of the trees. Civilization looks lovely and elegant from an airplane window. There is no need to agonize over street signs when you can clearly see how the roads connect. Exessive commentary would just distract the view and make you want to look away.

This reminds me of an astronomy presentation I attended a few years ago. The presenter was discussing his project's work of photographing the sky with an ultra high resolution camera. While I don't dismiss the importance of increased precision of scientific instruments, something about the approach seemed naive to me in the same way that commenting every line of code does. High precision comprehension or visibility should not set the attention to the little bits. Rather the increased resolution should feel more like a grid relaxation, as if the optics you're using to peer at the subject eventually, by refinement, itself becomes sufficiently imperceptible. Of the many wonders of nature is that much like a fractal, each scale presents a different structure. Think for a moment about photographing the sky with a multi-gigapixel camera. How far out from the earth in spacetime must you travel before each pixel contains an area larger than a galaxy? Are there galaxies visible to your camera that far out? What about the movement of the earth against an intergalactic background compared to the exposure time at that distance? If you wish to learn about a biological structure, like an ecosystem, or a plant, you don't invent an ecosystem- or plant-sized fine dicer, cut the subject into the tiniest pieces possible and then make a great deal of effort zooming in on your new collection of bits. The windowing function in this case forces such a bias that any phenomena observed must be of your own imposition.

Good commenting, like good programming, requires experience and discernment. If you really have so much to say about what your code is doing, consider a programming guide or notebook companion. Apply a rhetorical format that is appropriate for the topic. You would not discuss refinements you've made to a Fourier transform routine in the same way you would write down the shortcuts you took in a project due to business requirements. In the former case, you're complementing the code with exposition on the advantages and applicability of your enhancements vs a standard implementation. In the latter case, you're reminding the reader or yourself that a known substandard, but acceptable solution was adopted because of external constraints and that it needs to be replaced.

Most of the time effective commenting means adding comments sparingly. My rules for commenting I don't think are too much different from the standard wisdom and are slightly contradictory in their separate goals:

  1. Focus the commentary on what the code is trying to do and what deviations you may have made if any from a more conventional approach, e.g. did you have to workaround an upstream bug? Your reader already knows how source code works, so don't waste effort on describing how an if statement works. Do spend effort rephrasing an irreducible compound boolean expression in more colloquial language.
  2. Only write a comment if the block of code itself cannot summarize on its own what it is doing. Code blocks that cannot express what they are doing have limited maintainability. Sometimes this cannot be avoided if you're using an arcane language or are writing a performance sensitive or resource constrained application.
  3. If you need to comment one section of code, try to comment the other sections at a similar level to aid the reader in how the code progresses from top to bottom.
  4. Try to keep comments at the same level both indentation-wise and concept-wise. If you find that you need to mix more than a few lower- or higher-level comments in, then consider this to be a sign that your code itself spans too many structural layers and needs to be refactored such that the code block/namespace/module/class/object/function/expression in question has a well-defined scope and a more singular narrative of commentary.
  5. If your comment on one section of code is much longer than the others, or you find that you can't clearly and succinctly express what it is doing, consider this a sign that that section might need to be refactored such that its purpose is less fraught and more singular. (The reader (of this blog) is invited to think a moment at this point about Euclid's postulates and what wonderful things happened to geometry when the parallel postulate was finally resolved into a triplet state.) Cleverness is its own reward and almost never brings additional value. Code that is not maintainable is only disposable.

The Dystopia of Merit

I have long thought about the thesis of and cultured indignation against the rapidly evolving phenomena detailed in this article. I read/skim ~70 articles per day, so it is rare for me to read an entire article, but I recommend you to read this one as I have done. Normally I only have to read a few sentences or sometimes even the title and a few sentences before I can gauge the argument, tone, evidence, and novelty contained in an article, know how I will assent as much against my own worldview bias, or don't care. I have been reading the news for so long and have formed a comprehensive library of opinions and perspectives and can already reduce most articles to a few data transactions against the representative opinions. This is, however, the subject of another post.

What I have been thinking much about recently is a small portion of the meritocratic mania to reformat both economy and society into the image of a science fiction dystopia. My thoughts concentrate on two comparatively diminutive points within the scope of this dystopian realm.

The first is what I call the resume curse. Your previous work history tends to dictate the kinds of jobs prospective employers are willing to consider you for. Employers are most of the time unwilling to take or incapable of taking what they think is a risky gamble on someone without what they think is auditable experience. Stay in any one application stack or subfield too long, and you'll be asymptotically stuck to that stack or field, regardless of your as yet professionally unsubstantiated aptitudes in other areas. And should your unwittingly imposed expertise become factored out of existence, or worse, popularity by the industry, it's game over. Another hazard the resume curse creates is something like an inverted situation, wherein rather than converging you into a pigeon hole, your resume appears to present sufficiently much eclecticicity that your prospective employer characterizes your disparate tastes, or life happenstances as unfocused, undisciplined, and undependable.

The conventional wisdom here is that successful people create rather than take jobs. The probability of your next job being good or not depends on your ability to convince people that you can excel at the things you want to do. As trite as it may seem, most of the time this is achieved with some people sense and plenty of hard work.

The second scenario is complementary to the first and is called the goldilocks syndrome. Prospective employers are only willing to hire you if your experience in a handful of areas meets or exceeds their arbitrary, usually unrealistic, rubric. For example, 100+ years of C++, 25+ years of git, 15+ years of COBOL, 7+ years of go, srsly. (Also, Google has the resources to construct custom tools, libraries, even custom languages to exact more performance out of their custom technology stacks and then drop the gauntlet upon the world as open source projects. Why is it that everyone is compelled to appropriate their stuff with an inverted sense of attention to applicability?) I'm sure the comedic list of job requirements attached to most public job listings are the evidence of pandemic insecurity or ineptitude of HR departments desperate to regulate the job acquisition process in the wrong way.

The conventional wisdom is that good managers hire the best people they can find and then create a role for them rather than describe superman's exact history and sequence of errantry and then expect him to apply. (Withdrawing from the hyperbole for a moment, I imagine that what usually happens is that lazy HR grunts duplicate the toolsets and project history of the departing dev/admin at the company as the absolute verity for the job, and nothing less). The level of detail exacted often descends way down into bland detail, with strictures on shoe tying methods. Truly only superman ties his shoes correctly.

Adventures in Polyomino Tiling

Recently I began working on a recreational programming project that unites several subjects I have been wanting to explore for many years: AI, GUI programming, certain mathematical problems, and the intellectual zen and stimulus of gamifying them. My experiences with computer games growing up were quite limited despite that our family was somewhat early to install a 'family computer' in the library in 1992, a 80286 loaner at first and then a late model 386 with a turbo button on the chassis that doubled the CPU freq from only 33 to a screaming fast 66 MHz. I attribute this to my family's traditionalist values. Whether these positively or negatively curtailed my proclivities and aptitudes for computer-based labor, I cannot say for sure. It is true that I did not waste months of my youth on low quality game time, but I've never been wont for abdicating my languid and wastrel temporal habits. I recall several days or even weeks of boredom, and I am sure I have even made up some of the deficit in recent years with several offerings of temporal squandering in low grade video game time: a burning of time against the relentless scourge and depression of real adult responsibility.

Though I've never had the patience for most serious video games, nor the dedication and care to accommodate any I do find interesting with necessary computing resources--I'm insufferably opinionated over the most tedious minutiae and seem to exist in a perpetual state of annoyance even, or especially, when it comes to 'entertainment'--I do remember the halcyon days of sneakernetting copies of simulation games from my friend's house on a 3.5" floppy disk and covertly installing them on our family computer. My brother also found free demos of doom and dark forces online that have got me on a 90's retro Star Wars game tear lately, so long as they work in dosbox or wine. But I greatly digress. The topic here is polyomino games, specifically a game format that is as captivating as it is simple: tetromino tiling.

I used to play ksirtet in the KDE 3 days, but they didn't port it to QT/KDE 4 and the replacement didn't have all of the configurable keyboard shortcuts that ksirtet had. Ksirtet added two features that meaningfully enhanced the gameplay in a way that lowered the threshold for the zen state: translating pieces to the left and right sides of the board, and showing a shadow (a projection) of the piece under the bottom of of the tile board. This allowed you to maintain constant focus on the existing tiling state while simultaneously processing everything else with peripheral sight.

This is my second attempt at reimplementing ksirtet, the first devolved rapidly into vapid, desultory digressions on generalized multidimensional polyomino tiling problems and algorithms. Fortunately, now that I'm older and less idealistic--more impatient, perhaps--I've made some progress. I can't claim much so far for myself as I copied the code directly from Jan Bodnar's excellent wxPython demo tutorial, for which he also has a parallel pyQT version. I'm still evaluating whether to continue with wxPython or not. The relative elegance of the GUI framework will hopefully matter little to me and I may make a change if it results in drastically simpler cross-platform dependencies.

Screenshot of pySirtet 0.1

pySirtet 0.1 in action. Version 0.1 is basically a refactor of the zetcode demo. I've made the code more pythonic, and defintely a little more justinesque.

If you are interested in the game, you can follow the development on GitHub. I have been moderately impressed with the quality of documentation

and good information (as stackoverflow Q&A's, for example) on wxPython online so far, so I may stay with wxPython for now, despite that Phoenix hasn't molted yet.

On Learning Maths

While imagining how awesome of a maths and philosophy teacher I am going to be for my daughter, whose patience occasionally expires in expressions such as "dad, you don't have to teach me all the time", I recalled my own experience with elementary maths and how wastefully and long I fought against both the formalism and, more significantly, the threat and charge of inadequacy for miscomprehension or substandard performance--so much for meritocracy.

The first real arrival a student experiences in the primary education of mathematics in the US is elementary algebra, which is something of a sterilized and frustrating scope from the wonderfully weird and bizarre natural scape of algebra. The subject of elementary algebra is necessarily constructed from two theories: the theory of equations and the theory of functions, and typically features a myopic fixation on polynomial functions. Neither command of nor felicity in the topic can be attained without a fluent proficiency in both theories. For me, it was not until I took foundations of analysis, well into a maths BS, taught by a practicing mathematician at a research university that my understanding of these two theories was finally made clear. How much more advantage that my daughter would have then I, I thought, to learn from someone who knows the rigor and loves the subject.

There are other mathematical lexicons so fundamental to their domain, and all those that derive therefrom, similar to the theories of equations and functions, that I wish I either had had the intelligence to recognize or the fortune in a teacher wise enough to make it clear when I formally began learning them. The first comes from the theory of differential equations and the second from the theory of probability. Fluency in elementary algebra and calculus is not sufficient to be successful in constructing and applying differential equations and their solutions or appropriating their models. The same can be said about elementary algebra, some of whose ancient practitioners conjured wild scenarios to solve as if by magic. But since we are to learn that elementary algebra only has merit in the service of other topics, specifically those that form the mathematical prerequisites for a proper engineering education, no such interest or wonder was ever afforded by me to the magic of long form word problems in elementary algebra and how the application thereof is artful or captivating. A proper engineer's pursuit, however is the creative and discriminating application of differential equations, both ordinary and partial, and their solutions. Again, it was not until my second semester of graduate quantum mechanics that I think I really started to see such maths in nature. Once you learn the ways of differential equations, you never look at things in the same way again. You see them as boundary conditions, resonances, and decays.

The last item comes from the theory of probability, is more of a concept than a dialect, and is called a random variable. Like differential equations, which can be seen as a generalization of the theory of equations to which the solutions are functions rather than variables (sets), random variables generalize the meaning of a variable in ways that are profoundly insightful to any field that applies maths to reality, but a full comprehension for me only came together near the end of my first semester in undergraduate probability.

My relative travails in each topic I think demonstrates my own daft beginnings more than anything else. We know so little about ourselves in the beginning and how we learn. Mathematics has never been easy for me and despite the unrelenting contrary accusations. It is a fulfilling competence that was refined only through years of intellectual agony and determination. I think I was improbably lucky to have obtained and retained a handle on its innate, sublime beauty from when I was very young.

Maths is a language but they are also a curious collection of disparate locales with translations and orthonormal purposes as needed. Seductive formulas such as the complex exponential and elliptic curves belie an awesome variety and utility underneath their deceptively simple forms and we conjecture about yet more ambitious, unified truth from simple forms. I always return to Hilbert's defiant declaration:

Wir müssen wissen.
Wir werden wissen.

and wonder what weird meaning is wrought from raw logic in the human mind against its eclectic Condition and whether that construct really does sing the music of the universe, or the mad phantasms and sprites that spring into consciousness or both.

Setting Up Blog

I've always been wary of third party and/or hosted web publishing platforms, but it seems that there are plenty of lightweight static blogging engines out there. For me it came down to pelican and nikola, wherein I chose nikola. Mainly I wanted something that advertised full support for rST, and a few other niceties, such as tags and comments.