Saturday, April 6, 2013

The tragedy of music, part one

Once upon a time, people noticed that certain sounds are pleasant to hear, while others are not.  They began to experiment with it.  The most important early discovery in this vein was the notion that sound is vibration.  This is the fundamental principle of all musical theory, modern or ancient.  The next discovery was that of the octave: If you make two vibrations, one at double the frequency of the other, they sound... the same, in some way.  The faster one is clearly higher pitched, but they're harmonically equivalent.

The Ancient Greeks built upon this discovery, and eventually produced what we now call Pythagorean tuning.  Pythagorean tuning is built around simple frequency ratios; systems like this are called "just intonations."  The most important ratio other than the octave is the so-called "perfect fifth," which describes a gap of five staff positions in modern musical notation.  It spans a gap of seven semitones; there are a total of twelve semitones per octave in "conventional" systems such as Pythagorean tuning.  In Pythagorean tuning, a perfect fifth is a ratio of 3:2, meaning the faster vibration oscillates thrice for every two oscillations of the slower vibration.  So far, this is all very nice, and fits in well with the Pythagorean mathematical ideals of rationality.  But there's a problem.  I told you that a perfect fifth has a ratio of 3:2, is composed of seven semitones, twelve of which make up an octave, and the octave is 2:1.  Suppose we start at middle C (or C4), and move a perfect fifth up.  We arrive at G4, at 3:2 times our original frequency.  We continue to D5, at 9:4.  Next comes A6, at 27:8.  Then E6, at 81:16, B7, at 243:32, F♯7, at 729:64, C♯8, at 2187:128, and finally G♯8 at 6561:256.  Now suppose we go down from C4.  We find ourselves at F3 at 2:3, B♭3 at 4:9, E♭2 at 8:27, and A♭1 at 16:81.  The ratio from C4 to A♭1 is 81:16, and the ratio from G♯8 to C4 is 6561:256.  Multiplying, we see that the ratio from G♯8 to A♭1 is 531441:4096.  But A♭ and G♯ are supposed to be the same note.  Going by octaves, we should get 128:1.  The other ratio is rather large and unwieldy, because we have seven octaves of space, so if we divide those out, we get a ratio from G♯ to A♭ of precisely 531441:524288.  This interval is called the Pythagorean comma.  It's the difference (remember, in music, we never add or subtract frequencies, so this is actually the ratio) between a chromatic and a diatonic semitone, among other things.

So what does this actually mean?  It means Pythagorean octaves overlap, if only a little, since G♯ is a little sharper than A♭.  That's a problem for perfect fifths.  One of the twelve "perfect" fifths is ruined by spanning this overlap, being flattened to a rather dissonant diminished sixth.  So Pythagorean tuning, for all its beauty and simplicity, is not perfect.

Updated: In part two, we discuss quarter-comma meantone, a derivative of Pythagorean tuning.

Friday, January 18, 2013

One-time pads with Python

A one-time pad is a kind of unbreakable encryption.  For most encryption, breaking it is a matter of throwing a lot of computational resources at the problem.  Typically, the amount of resources needed greatly exceeds the amount that is practical to obtain, so most modern cryptography is secure enough.  There are, however, some downsides to modern cryptography, the biggest of which is its complexity.  If we want to use crypto for something like bank transactions, complexity is not that big of a deal, because centralization can hide most of the complexity from end-users.  But if, for instance, you need to implement secure communications without a centralized certificate authority, effectively implementing secure communications becomes a lot harder.

Wednesday, August 8, 2012

An exercise

Sometimes, I feel like stretching my programming muscles.  A while ago, I read about this problem, or one like it.  It's not an especially hard problem, but I'd like to go over it anyway, because low-level data types can be unintuitive.

Suppose you have two integers a and b.  You want to add them, but you also want to be sure they don't overflow.  You're working in a language where overflow is undefined, such as C.  You can't use arbitrary precision variables or anything fancy like that, nor can you make use of low-level things like CPU overflow detection.  You need to guard against overflow mathematically, without the use of any of those systems.  Maybe you're working on a reduced architecture that doesn't provide overflow detection.  Maybe your language or library is deficient and lacks an arbitrary precision integer type.  It doesn't really matter.  The point is, taking away all those "outs", we're left with a somewhat interesting problem.

Here are some assumptions you may make:
  1. You have a constant called INT_MAX which is equal to the largest integer which can be represented on your system.  You also have another called INT_MIN, which serves a similar purpose for the smallest (most negative) integer.
  2. You're working in two's complement, but overflow is still undefined.
  3. You do not have the exact number of bits available (but you could figure it out from INT_MAX, so that's not much of a restriction).
  4. You may throw an exception to indicate an overflow condition.
Actually think about this problem for a few minutes.  I'll put the solution after the break.  I really think most people who are likely to read this blog can solve this on their own, so please actually try this.

Sunday, July 22, 2012

Why I turned off Firefox's inline autocomplete

Firefox's location bar inline autocomplete is, for me, the single most annoying aspect of Firefox 14. Here's a list of why I'm annoyed:
  1. Pressing tab navigates to the first dropped down suggestion. It has no relation whatsoever to the inline suggestion, contrary to appearances, and doesn't let me edit the URL before navigating to it. 
  2. Pressing backspace removes the inline suggestion, but doesn't erase an actual character that I've typed. This throws off touch typing
  3. When I'm typing a Google search, if Firefox thinks I made a typo, it adds ">>" followed by the "correct" search terms.  I've had false positives here, and pressing enter searches the whole thing, which I find confusing.  Maybe there's a "right" way to use this feature, but if that's the case, then in my opinion it's poorly afforded.  Or maybe Mozilla really thinks people want to search for both correct and incorrect terms.  I don't know.
  4. Pressing enter goes to the autocompleted URL or search terms, instead of whatever I actually typed.  Since I often type rather quickly, this frequently results in searches for the wrong keywords.
  5. If I want to edit the autocompleted URL (e.g. to add additional fragments to it), I have to press the right arrow.  This takes me off the home row.  It is intuitive to use tab for this purpose, but that does something entirely different (see point 1).
  6. Last I checked, I wasn't able to find any addons on AMO to address any of these issues.  It's as if the new autocomplete fell out of the sky one day.  The only addons I was able to find were all about adding inline autocomplete to older versions of Firefox.
I like Firefox, and use it as my primary browser.   But I see this as a major blemish, and I went to the trouble of disabling it completely.  Here's how:
  1. Go to about:config in the location bar (Blogger refuses to link to it, unfortunately).
  2. If Firefox warns you, click through the warning.
  3. Type browser.urlbar.autoFill in the Search box.
  4. Double click the first result.
  5. You're done!  No need to restart the browser or anything.

Saturday, July 21, 2012

SpaceChem optimization

SpaceChem is a programming video game disguised as a chemistry video game.  A static description cannot really do it justice, so here's a trailer:


Honestly, the trailer doesn't do it justice either, so maybe you should go grab the demo from Steam.  Anyway, SpaceChem has two types of puzzles: Research and Pipeline puzzles.  Research puzzles are fairly straightforward to work with because an input/output operation always takes exactly one cycle, whereas with a Pipeline puzzle, the tubes pipes can be clogged or empty, making your I/O operations block.  This means that performance problems with one reactor can affect others.  But optimization is not an all-or-nothing affair.  You need to know where to concentrate your work.  That's what this post is about.

Thursday, July 19, 2012

Do we even need copyright?

As we established last time, copyright is an indirect subsidy.  The purpose of this is to incentivize creativity, the idea being that art for its own sake is important, but won't pay the bills on its own.  But art has a nice property: people like it, especially if it's original and well-executed.  As there's both a supply and a demand for original, creative expression, I must wonder whether the market can connect the two without the use of a subsidy.

Saturday, July 7, 2012

The worst-case scenario

A lot of the lessons from Fukushima have been obvious for a while. Nuclear safety is a global challenge, and every country has to learn from the best practices of others. These best practices include retrofitting passive safety features wherever possible, and continuing to update safety measures in response to our changing understanding of the plant's environment. -- Ars Technica (emphasis added)
 This advice certainly sounds right, to me.  But when I check consequentialism, I find that the words "whenever possible" give me pause.  On the one hand, it seems that our only question should be "What effect does a given safety measure have on actual safety?"  But proper consequentialism requires a two-sided analysis, so we must also ask "How much will this cost in relation to the expected number of lives saved?  Is it worth it?"

I don't like this conclusion.

It certainly seems logical enough: if we're to make a change, we must do a proper cost-benefit analysis.  But imagine this hypothetical: you're provided with an investing opportunity.  The expected value is better than any other investment you're likely to find, and you're sure that it is legitimate.  However, it's a risky investment, with a chance of returning nothing at all, not even the money you put in.  I don't think any sane person would invest all of their money in such a scheme, and I don't think this falls under irrational risk aversion either.  Yet that is exactly what basic economics (which is very similar to utilitarianism) says we ought to do, perhaps leaving some money out for basic living expenses, but certainly without a safety net.  If someone did invest all their money like that, and ended up bankrupt, they would have only themself to blame.

Of course, most real financial analysts would never do this, instead preferring to diversify.  But I can't understand how you get from "throw all your money at the best expected value" to "diversify", and I think it's just a kludge to make the system work right.

What can we distil from this?  I think it's clear that we need to consider the worst-case scenario in any evaluation.  But which one?  A situation can always be worse.  So, to keep this reasonable, we need to limit ourselves to outcomes which are related to the proposed action: those outcomes whose probabilities are significantly affected by our proposed action.  Of those outcomes, we should focus on the very worst.  We need to ask ourselves "Is this outcome tolerable?  What effect does our decision have on its likelihood?"

But what of utilitarianism?  This doesn't seem compatible with it.  I feel that we may revise utilitarianism if we find it necessary; I may explain why in a later post.