Monthly Archives: February 2005

We have a movement

More than three months of work has yielded the first movement of my piano concerto. Woohoo! MIDI|MP3 (running time: 8:30)

The piece still needs to be edited. The score is not pretty (it uses incorrect accidentals here and there, and I think the brass section, the clarinet, and the piccolo are still feeling left out, and I might be asking the cello section to do intervals that they’re not capable of). I think I’m going to postpone editing until I’m done with the whole concerto, though, because I’ll probably be a better orchestrator by the time I’ve written another 20 minutes of orchestral music. Then I’m going to take it to the CU music school and see if any orchestrators want to edit it (again). And then I’m going to search for somebody to perform it, however I might go about that. But that search is a good nine months down the road, so I’m not worrying about it just yet.

Logarithmic Units

I’ve been thinking about units a little bit. Seldom do we come across unitless quantities; they only seem to come up when you’re talking about a ratio of two things. We can always add two quantities of identical units… except in one place.

The following program does not compile:

    int main() {
        int foo, bar;
        int* p = &foo + &bar;

If we attach standard physical-style units to these things, there is no reason this should be an invalid operation. We’re adding two int*s, or more generally, two of whatever you get when you take the address of an int together. And yet, it dies. And rightfully so: the operation is meaningless. So what kind of unit is int*? What kind of unit doesn’t allow you to add another unit of the same type?

I’m calling it a logarithmic unit. It makes sense if you define the program in pseudo-C:

    int main() {
        int foo, bar;
        exp(int*) p = exp(&foo) * exp(&bar);

Now the error is obvious. We’re assigning a quantity with dimensions exp(int*)2 to a variable with dimensions exp(int*). But we had to multiply instead of add.

So let’s fix it and then take the natural logarithm of the whole expression:

    int main() {
        int foo, bar;
        2 int* + p = &foo + &bar;

And now it’s clear what kind of unit a pointer is: it’s an int*+. A logarithmic unit. And look, it works perfectly with adding pointer differences, a perfectly well-defined operation in C:

    int main() {
        int foo, bar, baz;
        int* + p = &foo + (&baz - &bar);

With units, the expression is:

        int*+ p = (int*+ &foo) + ((int*+ &baz) - (int*+ &bar));

If we consider int* just like any other symbol, the units work out perfectly. And what, then, is the dimensionality of ptrdiff_t? Why, it’s unitless, of course, just like a ratio.

Another case of logarithmic units that we just ignore: the Farenheit and Celcius temperature scales. One that we do pay attention to is the bel, but it is dimensionless. When you add dBs, you’re really multiplying something.


I awoke at 9:00pm (my schedule has been wacko this week), pushed the alarm time button, and saw “1:50”. Why didn’t it go off? Why, because it was set to 1:50 AM! A lot of good that does. So I missed the Perl 6 meeting and my classes at 4 and 6.

But, some good did come out of it. I began a song at 10:00pm and finished at 4:30am. It’s the first movement of a string quartet. That will give me something to work on when I have writer’s block on my concerto (which I do right now). Here’s what I wrote: Andante.

UPDATE: And here is an MP3 for the MIDI-disabled. It’s not going to sound that realistic because my solo string samples aren’t very good; in particular, pretend the crescendos are actually getting louder (the samples have long attacks, which isn’t good for fast songs). Anyway, my string samples are probably better than yours, so err on the side of the MP3.

Ideas and Graph Theory

Here’s an interesting problem. Consider n people standing in a circle. Each person knows the person just to their left and just to their right. Each person also knows (at most) one more person in the circle, which you, the problem solver, get to choose for them. You give one person a paper with a 0 on it. He’ll give each person he knows a paper with a 1 on it. Each of them will give each person they know a paper with a 2 on it. And at each step of the game, if a person has two papers of different number, he’ll burn the larger one. The question is: when everybody has a paper, what is the maximum number that will be written on any paper, where you’re choosing the graph configuration to minimize this number? Just to check yourself, the first few are n=4,5,…; N(n)=1,2,2,2,2,2,2,3,3.

Thinking Like a Designer

Putting aside any fears of seeming pretentious or arrogant, I’d like to write about my software design strategy. I consider myself a pretty good designer, and although I haven’t written that much, what I do write comes out clean, maintainable, and versatile. In the process, I’d like to talk about my new idea for an open source music composition program, and use it as an example.

The first thing you need in a project is your design goals. Most likely, somebody else has done the same thing you’re about to do, so your design goals tell you how your project is going to be different or better than those other poor fools’. For instance, Subversion set out to be CVS, but not broken (well, it was a bit more specific than that).

Let’s start with the design goals for my music project. Indeed, there have been attempts at previous composition programs before, but they never seemed to get anywhere. Some of the limitations were: too notation-driven (lilypond—the only successful one), too big a task (i.e. trying to do too much at once, and since this is open source, getting nothing substantial done). I’d also like to incorporate my music-wiki idea. So let’s come up with some design goals:

  • Composition focus, but not exclusively (addresses the first problem). That is, focus on the notes, not the presentation.
  • Component-wise (addresses the second problem). That is, my program is actually a suite of related little programs—or little libraries. It means that I can prototype the big concepts of my software without going into huge detail.
  • Software-unbiased, related to the previous goal. So I could let somebody else write a notation program to go with my composition program, and it could work smoothly.
  • Text-friendly (addresses the music-wiki goal). I want changes to be mergable, using the patch program.

Continue reading Thinking Like a Designer


I had an archimedes moment this morning just after I woke up. I was thinking about the function tan-1(x-1) and it’s peculiar discontinuity. I wondered if you could do that kind of “finite discontinuity” with a composition of ratios of polynomials, and concluded that you can iff the limits at positive or negative infinity of the ratio are noninfinite and not identical.

Theorem: For any two polynomials P and Q, let f(x) = P(x)/Q(x). Then (limx -> inf f(x) = +-inf, and limx->-inff(x) = +-inf) or limx->inff(x) = limx->-inff(x).

Proof: (Informal) If P and Q are of different degrees, then both limits are +-infinity or zero. If P and Q are both degree zero, then both limits are a constant, namely P(0)/Q(0). Assume that the conjecture is true for degree n polynomials. If P and Q are both degree n+1, then due to L’Hôpital’s rule, the limits are the same as in P'(x)/Q'(x), which are degree n. QED.

So the result is that no, you cannot. If there’s a discontinuity in a composition of ratios of polynomials, it is an infinite one.