September 29, 2004

Journal Club

I'm expected to do a journal club presentation once a semester, and I leave the country on Friday. So that leaves tomorrow.

Title: "Two recent papers on B-mode contamination in CMB polarization"

List of relavent abstracts from ADS

Polarization from Secondary Vector and Tensor Modes

Lensing as a Contaminant

Hu, Dodelson review paper for background

astro-ph entry for above (to get the figures)

Posted by mill1974 at 9:00 PM

Techno-political Anthropology

A fascinating, if less coherent than I would like, article just went by in the Anthropological Quarterly, linked to by this Groklaw article, with additional discussion. The thesis of the thing is that FOSS has gained its pervasive and thus highly potent status as a movement precisely by virtue of its apolitical nature.

This strikes me as a smidgeon sloppy, since FOSS advocates routinely intervene in politics, on issues that touch upon our ability to develop software. Just because the community backs no particular candidates (the leanings probably average out to slightly libertarian) and would generally rather change the world through good software, does not mean that it lacks political goals.

Since the idealized FOSS community is, as noted elsewhere, a "transparent meritocracy," there is little patience for popularity contests, and where they do crop up (e.g. vi versus emacs), they are couched in the language of technical critique. This leads to an appreciation of law as code, and specific proposals as correct or incorrect, characterized both by the likelihood of beneficial or deleterious effects, and by the potential for unforseen consequences, a la "bugs" in the legal code. Politicians are characterized as using legislation to advance or hinder a particular agenda. This is loudly condemned by the FOSS community as being beholden to external interests, rather than to the people whom they represent.

The contradiction here is that the FOSS community quite naturally has an agenda of its own, namely, technical excellence and the freedom to strive for that goal, unmolested by legal interference. However, since the community conceives of itself as an essentially populist structure, due to its distributed nature, a politician acting in its particular interest would be acclaimed as working "for the people."

Posted by mill1974 at 4:43 PM

September 23, 2004

Long Term

I've always considered myself a long-term thinker: the primary importance of the present is the impact it will have on the future. This point came up over dinner last year with Dr. Jill Tarter in relationship to both her specialty, interstellar communications, and to more worldly concerns like ecology and the likelihood of humanity's eventual extinction.

She pointed me to the Long Now Foundation as a seminal effort towards this kind of mindset; I find their focus on the coming ten millenia admirable, if still somewhat short-sighted from the perspective of ecology, evolution, and sustainability. Nevertheless, I hope they eventually build their clock.

Just as a bookmark, I ran across The 10,000 Year Blog, which concentrates on long-term thinking, with an eye toward data preservation.

On the sustainability front, I recently found an example of real-world arcology discussion. Normally this kind of thing restricts itself to science fiction. Not that I don't also think they're a little nuts, since they manifestly fail to even begin thinking about how one transitions from the current state of affairs to the "arcological" city.

To return to the point raised in the first paragraph, my take on the question was that humanity either will or will not become extinct at some time in the future. In the case that it does not survive, the Earth's biosphere will recover in interesting and unpredictable ways, just as it has after every previous mass extinction. Naturally, there's no guarantee that intelligent life will arise again; that seems to be pretty hit-and-miss, although the fact that it only took mammals 100 Myrs or so to get there is not altogether disheartening.

Should humanity survive in the far future, we may assume that it has come to co-exist stably with its environment, since it is unlikely that it could survive perpetual chaos (if things look chaotic as far as you can see, look farther), which can happen in one of three basic ways. First, we may reach a stable equilibrium with the Earth's ecology; second, we may eliminate the ecology and thus inhabit a totally artificial biosphere; third, we may abandon the planetary environment altogether, by moving into space.

This, I think, is pretty well-founded reasoning. If one were to ask for my own opinion, I would speculate that things don't look good for biological homo sapiens, on the simple basis that almost no complex life forms have persisted for more than a few hundred million years. And crocodiles, we ain't.

On the other hand, I would hold out a tentative hope that our intelligence, and perhaps even some scrap of our own civilization, will survive in our descendants, be they AI robots, bioengineered humans better suited to ecological equilibrium or space travel (or both), or what have you. As I write that, I can hear my DNA complaining that I'm supposed to want to perpetuate it, but perhaps we can all be grown-ups and decide that our mental genes will do, whatever those may be.

Posted by mill1974 at 10:42 PM


Obviously I knew of LJ -- any number of my friends use the thing, and apparently a significant chunk of the teenage-twentysomething set does likewise. So I was rather interested to run across this presentation on slashdot detailing the architecture and evolution of the system. Particularly when it led me to discover that the LJ software is actually open.

I must say, it always does my heart good to see a major software project running on Perl -- it may be my favorite language, but it just doesn't get the press of Java or the fanboy devotion of Python, despite being highly useful for the same sorts of tasks, and better at a number of them.

I'll even forgive them for rewriting memcached in C -- Perl isn't really made for pushing bits around, after all. Cool idea, by the way, to use spare memory on your servers as a distributed disk cache, although it seems that you must have an awfully fast and uncongested internal network for that to be faster than disk seeks.

Now I'm wondering if there are bits of the LJ code that would be useful for the ScavCode project. There are certainly ways in which a blog-like functionality could be a useful complement to the wiki paradigm, on the front end. On the back end, my hand-rolled database interface has always been a bit of a kludge, out of the necessity that one guy be able to maintain it. Maybe I should look into how LJ does it.

Posted by mill1974 at 9:59 PM

September 21, 2004

Travel Blog Titles

Started working on graphics for the travel blog, to open here in a day or two. The most important factor, of course, remains: the title.

The following list wound up in my notepad. Some obvious themes seem to peek out.

  • Place, Deconstructed
  • Texan, Delocalized
  • Demythologizing Place
  • Geospatial Fetishization
  • Locality Fetishism
  • The Cult of Place
  • Anthrogeospatial Adventures
  • EGAD: Empirical GeoAnthrospatial Didacticism

I spent some time this afternoon making a cool graphic for the masthead if I settle on the last one there. Or, actually, anything that anacronizes to EGAD.

Of more concern out in the real world, of course, is setting up appropriate templates so as to avoid, gasp, exposing the public to the default MT style, and then writing up a few pilot posts about the recent trip to New York. Also, I might do some work at some point.

Late update: Sept. 23

And, we have settled on a rough blend of the above, in the grand tradition of not settling on a title. It is: EGAD ... or, (de)mythologozing the fetish of place. Check it out; I'm fond of the design. Vaguely reminiscent of sand and sea and sky.

Posted by mill1974 at 7:52 PM

September 14, 2004

Chicago Winter revised

Yesterday I finished this summer's project to revise the Chicago Winter poems. I think the result is somewhat stronger, and vastly more cohesive, than the previous version.

For reference, a PDF copy (nearly identical to the one I sent Dad and Bonzzi for review last night) is on the flash drive along with the text files.

Which brings me to an interesting point. I have long complained that, much writing as I do on a computer, I can't really compose poetry electronically. This continues to be roughly true, I think -- the spontaneity of a pen on paper, the complete lack of formatting restrictions on what I write or how I write it, and the freedom from technical details of insertion, deletion, and version control, mean that I will probably continue to write and revise poetry this way.

That said, an electronic format is vastly more convenient for storing the resulting mess of poems, revisions, words and associated dates. So after each revision, I type the changes into a copy of the previous version, give it the next available version number, and dump it on the flash drive (for portability). This also lets me do cool things, like write a few little Perl scripts that read in the text and autoformat it into Latex for printing. One more tweak, and it'll even let me keep a versioned table of contents, and will auto-assemble the entire collection.

I am still conflicted on one question, though: should I keep the paper revisions that I've written all over as a backup, or rely on the sequence of digital files to be my record of each poem's evolution?

Posted by mill1974 at 2:56 PM

Music Hacking - Observations

Recently, I got the environment working here on vader, first using just the beep program, and later with OSC messages to SuperCollider. I'm hearing a lot of static, though, which makes me think that kernel latency issues might be cropping up.


Getting the thing working with beep was easy (although Beep::Linux, like most other non-core modules, needed to be compiled from CPAN -- the OSC modules even needed a separate patch). Installing SuperCollider was likewise a snap, from Debian packages.

Trouble ensued. The biggest source of difficulty arose from my failing to understand that the sclang client is also an OSC server in it's own right, and that the messages from are actually intended for the language engine, to trigger routines that, in turn, tell SC to do stuff. So I wrote a launch script for SC so I could be sure of where it was, and a conf file for sclang for the same reason (and while I was at it, made sure everyone was automatically talking to Jack correctly, so I could stop constantly relaunching it and redefining the connections), and lo, the messages flowed, and beats resulted.

My suspicion is that if I can get Jack running at appropriate priority, the sound quality will be better. However, it may be the case that SC also needs priority.

Code ~= Tunes

Obviously, considerable experimentation will be needed to get anything pretty out, although I've already noodled around a bit with modular arithmatic as applied to both polyrhythms and manipulations of tone sequences, with not wholly unpleasant results.

The first works something like this:

{ ...
$s->play($note1) if ($beat % 4 == 0);
$s->play($note2) if ($beat % 7 == 2);
... }

Obviously, this will give you a recurring pattern with a period of 28 beats; throw in more moduli to ramp up the LCM and eventually you could wind up with a pattern of substantial length. This will not give you much in the way of tonal structure, though, which suggests the second approach:

{ ...
    @notes = qw( A B C D E F G );
    %m = ( C => 60, ... );
    $s->play( $m{ $notes[ $beat % 7 ] } );
... }

This will produce a really boring (and without some division, quite up-tempo) do-re-mi sequence. But throwing in some additional arithmatic:

@notes = qw( 60 61 62 ... );
{ ...
    $notes[ $beat % $#notes ] -= 3 if ( $beat % ($#notes - 2) == 3 );
... }

The result is that the (now once-initialized, rather than being continually reset) note list gets morphed over time, as individual elements are transposed. Since the morph period doesn't match the list length, the transposition will march through the list in LCM[ $#notes, $#notes - 2 ] time. There should be compensating up-transposing members in there as well, to make sure the notes don't run off the bottom of the scale -- but exactly when this happens depends on the relative modulii.

More experiments will follow. But for the sake of my ears, only after I have the sound quality issues worked out.

Posted by mill1974 at 2:37 PM

September 7, 2004


I will be writing a novel for NaNoWriMo, a blogosphere phenomenon calling itself National Novel Writer's Month. Must remember to actually register with the site, to get the bragging rights, should I achieve the designated length (50,000 words in a month).

Fascinating idea, really: harness the power of deadlines and a competition (however contrived) to encourage people to undertake a project that would otherwise remain forever in the realm of mental vaporware.

I've written more on my idea in the dead-tree journal, but the outlines are as follows. The novel is provisionally titled Causus Belli, strictly so I have a convenient handle by which to refer to it. Unlike Chicago Winter, this title should probably not stick. The story will combine two parallel but mostly non-intersecting plots, the doings of two individuals in the ancient Roman world, in the years leading to and during the Third Punic War. One will be a wealthy and moderately influential individual; the other an urban plebian.

The choice of setting, in addition to being a historically interesting and largely untapped period, is also motivated by the fact that a number of striking parallels exist between the Roman republic in the mid-2nd-century BCE and America in the present.

I must admit to a degree of apprehension about this undertaking. I have never had spectacular success with writing lengthy prose; my natural form tends to be the carefully constructed, dense poetic form. There is no guarantee that I will produce anything publishable. But I feel that it is definitely worth trying.

Posted by mill1974 at 8:24 PM

September 4, 2004

Free Desktop Publishing

Scribus, the GIMP, and one I hadn't heard of before, vector graphics package Inkscape -- evidently now the combination of choice for at least one commercial newspaper.

Not the kind of thing I actually ever do anymore, with all of my document production being in TeX and various visualization tools that happily spit out Postscript, but good to know about anyway.

Posted by mill1974 at 12:41 AM

September 3, 2004

Blogging Palestine

I have been encouraged by multiple people to start a blog to document my adventures in Israel, and other locations I may visit on my upcoming adventure. I think this is an excellent idea, which means it's time to become a blogger.

I should also invest in a digital camera. Nothing so expensive that I'd be heartbroken if it didn't come back with me. CF storage would be primo, since I can then offload them to the Gmini drive without an intervening computer.

Posted by mill1974 at 4:13 PM

Live Music Hacking

In Perl, no less!

This may be the coolest example of hacking that I've seen all week. He uses a very simple framework that lets him edit, in realtime, a program that algorithmically drives a sound synthesis server (SuperCollider here).

Before I read the article, I had some trouble visualizing how this would likely work. After all, I don't generally write programs that, after a few lines of coding, work at a basic level, and then do something more complex. Instead, after a few lines of coding, my programs don't do anything yet, and later there comes a kind of keystone-insertion point where the thing stands on its own, and does something resembling its final function.

This fellow's trick is to set up a framework that keeps him constantly at that tipping point between no-function and function, and what's more, able to continually reprogram, on stage no less, the shape of that last core piece.

So there's a framework; it's somewhat elaborate. There's a time server that can even keep multiple instances in synch, like a network metronome. There are some helper functions that mediate his connection to the audio equipment. And finally, there's -- sort of like an old-style LISP environment for Perl, he edits the inner event handler (which is, wonderfully, a continually re-evaluated data structure that is often, as a result, self-modifying) that dispatches events. An example is apropos:

Once everything is ready, run and type this little script in:

  # 231
  sub bang {
      my $self = shift;
      $self->code->[0] = '# ' . $self->{bangs};

Press ctrl-x and it will start to run. $self->{bangs} contains the number of bangs since the script was started, and this is written to the first line of the code (make sure that line doesn't have anything important in it). Calling $self->modified tells the editor that the code has changed, causing it to refresh the screen with the changes.

OK, lets make some sounds.

  sub bang {
      my $self = shift;
      my $note = 100;
      $note += 50 if $self->{bangs} % 4 == 0;  
      $note -= 30 if $self->{bangs} % 3 == 0;  
      $note += 60 if $self->{bangs} % 7 == 0;
      beep($note, 40);
      $self->code->[0] = '# note: ' . $note;

Hopefully this should play a bassline through your speaker. beep() is a routine imported from Audio::Beep; you just pass it a frequency in Hz and a duration in milliseconds.

Posted by mill1974 at 4:10 PM