February 6, 2007

Microcontroller Ideas + Scavcode

I should really learn how to work with microcontrollers, seeing as they're so cheap and ubiquitous these days. The Atmel AVR chips are supposedly very easy to develop with -- it's possible to build all the development tools from scap, if needed -- and have a well-supported open-source toolchain.

Some ideas for microcontroller projects:

  • Rocket launch coordination: it would be easier for THORHAMMER to reach target altitude using multiple rocket boosters, but they have to be ignited in a coordinated fashion. I would use a circuit that can sense whether each engine has fired, which would unlatch an electromechanical launch stop only when they are all lit. A human can't do this, since an engine only burns for a second or so, but losing the first few milliseconds of burn time should be fine.

  • Electric field mill readout: self-explanatory.

  • THOR onboard altimeter/data logger. Obviously only for the prototype.

Unrelated project: ScavCode -- it occurs to me that it should really be possible to train an OCR to read, given certain expectations of the list format, well enough to process digital images emailed from a camera or cell phone. Also, I did plan to release the code this year, which is still a worthwhile goal. Look at Gocr and OCRad as backends, and unpaper as a filter. Alternately, look at WeOCR web service.

Posted by mill1974 at 10:30 PM

December 7, 2006

XEphem in Debian

I think the time is right for a push to get XEphem back into Debian. The immediate problem is that x11-common has added a Conflicts: against xephem without any version specifier. XEphem hasn't been in Debian for a while now, but there are a couple of independently packaged versions -- since they're all named "xephem" this causes problems for those packages, too.

The original difficulty is that XEphem ships with a modified form of the Yale Bright Star Catalogue, which violates the license on that dataset. Since nobody stepped up to prepare a distributable version, e.g. using a freely distributable star catalogue, it was dropped after Woody. The new conflicting x11-common seems to have spurred some interest (bug discussion), and there does exist (for example) an EDB of the Hipparcos stars that would work legally. Apparently the Ubuntu users already knew this.

Longer term it would make sense to integrate XEphem into the stardata-common work by Kevin McCarty et al, which really shouldn't be too hard. If we're going to put in that sort of effort, it shouldn't be much work to create free alternatives to the planetary surface images and other extras distributed with the commerical version of XEphem, either.

Which brings me around to another tangent: given what an enormous pain such packages can be, wouldn't it make Debian a natural choice for astronomy if one could Debianize the installation and maintenance of things like Aips and IRAF? Someday I might be inspired to think about such horrors.

Posted by mill1974 at 1:43 AM

September 15, 2006

Methods and Properties of Triggered Lightning

From the UF Lightning Research Facility, their list of publications.

Pay particular attention to:

The most effective technique for triggering lightning involves launching a small rocket trailing a thin grounded wire toward a charged cloud overhead. This triggering method is sometimes called "classical" triggering and is illustrated in Fig. 1. The cloud charge is indirectly sensed by measuring the electric field at ground, with values of 4 to 10 kV/m generally being good indicators of favorable conditions for lightning initiation. When the rocket, ascending at about 200 m/s, is about 200 to 300 m high, the field enhancement near the rocket tip launches a positively charged (for the common summer thunderstorm having predominantly negative charge at 5 to 7 km altitude) leader that propagates upward toward the cloud. This leader vaporizes the trailing wire and initiates a so-called "initial continuous current" of the order of several hundred amperes that effectively transports negative charge from the cloud charge source via the wire trace to the instrumented triggering facility. There often follows, after the cessation of the initial continuous current, several downward dart leader/upward return stroke sequences traversing the same path to the triggering facility.

V. A. Rakov, SIPDA V

Posted by mill1974 at 8:39 AM

July 9, 2006

Bicycle Routes

Using the Gmap Pedometer's route saving feature:

Marcy-Holmes to Phalen Park, 12.3 miles: http://www.gmap-pedometer.com/?r=285589. Takes me 70 minutes each way. Pretty gentle throughout eastbound; the hairpin turn in Wheelock is a nasty hill going west, but it's made up for by the fact that the route is entirely downhill from the St. Paul campus.

Jess's place to the East Bank campus, using only beginner-level bicycle commuting routes: http://www.gmap-pedometer.com/?r=286299.

13.3 miles total, but this can be cut short just shy of 10 miles by transferring to a Campus Connector on the St. Paul campus. The diversion from Como at 27th is just to avoid loose gravel on the road from ongoing construction, which also affects 15th at the moment. The gravel actually starts at around 29th, but the freshly widened sidewalks are good for avoiding it, as are the nice wide sidewalks that line most of 15th. One would hope the entire situation would clear up on its own, but given the apparent pace of work that will take a while.

Posted by mill1974 at 8:06 PM

March 28, 2006


Thinking about how to adapt the old summer camp / dorm game of assassins to a grad school setting. More flexible rules to appeal to a more sophisticated audience, perhaps. Stringent avoidance of getting in the way of people trying to get work done.

Posted by mill1974 at 8:31 AM

January 24, 2006

Not quite a PIM

So the usual sorts of PIMs don't do me a whole lot of good. They generally try to do too much, or are too specialized, or some similar sadness. I use J-Pilot, a lightweight GTK Palm manager, for its calendaring, but that's about it. Here's what I'm really looking for:

  • Simple. A calendar and some to-do lists would really do it. My email program has all my addresses, my phone contains all my phone numbers, so the whole contact management stuff is unnecessary.
  • The calendar needn't do that much. J-Pilot does nearly all I need, except I'd like some little applet I could painlessly leave open to do alarms.
  • To-do lists look simple, but aren't. I want a basic bullet list that I can sort by date or priority. I want to be able to expand tasks into sub-tasks, a la Project schedules or *STeP directory panes. I want to be able to have a list of Big Goals, like papers and programs and other writing projects for the year. But the same interface should let me jot out a list of stuff for the week, or even just the evening. It would be cool to pull these little things out of bigger lists and have updates link back, but I don't know if I'd seriously use that.
  • Portable-centralized-distributed: J-Pilot ties me to the system with the program, so it only gets used for stuff that happens at my desktop. That's why I stopped using its to-do lists -- those I want to carry around. A web app (wiki, at simplest) has an interface that's limited by the browser; though AJAX helps, not all platforms support a powerful enough browser, and native interfaces aren't a bad thing. So I'm thinking a central repository on a server somewhere with RCS-ish semantics that speaks XML in HTTP/multipart messages. A client app checks out the current state and caches; mods can be merged/synched in anytime later. Maybe with a secondary IMAP or other heartbeat protocol to push update alerts.
  • With a family of related client apps, formats become less of a problem. A web app could be a client, but so could my little alarm applet or a full-blown Evolution-esque beast. So could a form generator to spit out a printable grocery or errand list, or a .pdb generator to stick lists or calendar stuff into a Palm, etc.
  • To reduce the amount of data passed around, certainly compressed HTTP bodies are good. Clients should probably be able to ask for a window of dates of interest. Doing real diffs would require real revision tracking, which might not be worthwhile, but if there's a file representation of the backstore somewhere, rsync-like tricks could work.

This seems like something that is surely a solved problem somewhere, but I haven't seen it. For some reason, I want to call it VILMA if I wind up writing it. The last bit stands for Life Management App, but the VI eludes me. Very Intuitive? Probably not.

Posted by mill1974 at 6:33 AM

October 13, 2005

Post-Oral Exam Projects

  • Scavhunt software
    • cleanup
    • meet existing requests (w.r.t. more database queries)
    • multi-team!
  • Learn Google Maps API
    • Mpls bike map + Gmaps
  • Write!
    • Walls essay - submit
    • Chicago Winter - time for another editing round ... submission?
    • new material
    • Rome?
Posted by mill1974 at 6:14 PM

June 5, 2005

Summer Reading List

Starting in July, I'll have access to American libraries and bookstores again. Let's use the comments as a scratchpad to make note of books I've been meaning to read.

Posted by mill1974 at 3:35 PM

May 24, 2005

Revisions observation

Note to self: print out the Walls essay so you can do revisions offline.

Something I've discovered about working 12-hour days on a computer -- I'm kind of sick of sitting down at computers by the time I get out of the office / lab. This makes it difficult to do, e.g., essay revisions or other composition work in digital form. I may need to revert to hardcopy just so I have the option of working on it out on the lawn or in the dorm common areas.

Hazards of being a grad student. This has also played havoc with my development schedule for my software projects. Hopefully this difficulty will resolve somewhat by next year if I'm spending more time working on hardware in the lab.

Posted by mill1974 at 2:25 AM

May 21, 2005

Astrophotography category

Just a note for sometime when I've got some spare time:

I should create an astrophotography category on EGAD, and add it as a secondary category to all of the various astro shot posts.

Posted by mill1974 at 4:53 PM

Tangled Bank

Tangled Bank #29 will be hosted at Organic Matter this coming June 1. My recent EGAD post Optical Design would be a good submission.

Also, it would be interesting to pull together a good post on the geohydrology of the Levant and aquifers, and how they relate to human water supplies. This would tie together Water (on the water dimension of the Israeli-Palestinian conflict) and Still Thinking About Water (which contrasts Phoenix's water plight to the aforementioned) with some actual science. That would also be a good Tangled Bank submission, but I might not get to that until after June 1.

Posted by mill1974 at 3:20 PM

May 10, 2005

PageCapt retrospective

In the aftermath of the Hunt, two categories of problem present themselves:

(Mind you, this is all separate from general complaints such as, "the site isn't very usable or intuitive." I know that already.)

Tasks People Couldn't Do

That is, things that needed to be done, but were impossible to do through the web interface. For instance,

  • Edit items. Now that we can input them, proofreading and correction seems mandatory.

Questions People Couldn't Ask

As opposed to things to do, these are questions people wanted to ask of the database, for which I had to manually log in and execute an SQL query to extract an answer (or, in a couple of cases, compose a custom page).

  • Which items' comments contain a key word?
  • Show me the phone number / meal points / talents for all users.
  • Which users use a keyword in their connections / talents?
  • Which users live in Burton-Judson?

April 5, 2005

File Taxes Online

Turbotax online for free if you qualify, which I almost certainly do.

IRS codes for US citizens abroad never explicitly states how to report foreign income when they don't have the equivalent of a W-2 to give you.

Posted by mill1974 at 7:54 PM

March 29, 2005


Latex is cool. Latex on blogs is an obvious application thereof.

LatexRender is a PHP script that does the usual Latex->ps->image conversion, a la LaTeX2HTML, but on-demand in response to stuff in a post/comment/whatever.

There's some preliminary work on getting it to integrate with DokuWiki, but it's not ready for prime time yet. Pity, since if we're going to be heavily using wiki sites for lab collaboration, this would be handy.

Posted by mill1974 at 5:29 PM

March 25, 2005

Linux Math

List of mathematical software for Linux -- thorough.

I should spend some more time browsing around to find new tools of interest.

Posted by mill1974 at 10:24 PM

February 23, 2005


Giving Textile formatting a try in this post. Mostly was seduced by the easy footnoting used liberally over at CT.

Textile 2

Textile 2 manual

Posted by mill1974 at 10:42 PM

February 2, 2005


Not what you think.

The Indiana University Library has put their book conservation manual online.

I am reminded that I borrowed Paul's copy of Jackson on the condition that I'd give it back in improved condition. It needs re-casing.

(Found that link on this comprehensive links page at the Book Arts Web.)

Posted by mill1974 at 4:06 PM

January 4, 2005

Not quite bookmarks: software

Kieran Healy maintains an interesting weblog (one of the CT feeders). Still catching up on stuff I missed while traveling, ran across this today. Not unlike my own software recommendation rant, but more pointed, and of course somewhat specific to sociological (or at least statistics-heavy) academic work.

Led me to wonder if Unison mightn't solve some of my problems with having so many workstations and laptops in circulation.

Also got me back to thinking about general ways of integrating literate programming into my workflow. I don't actually originate enough code or text for it to be an issue yet, but it will. And in a different direction, reminded me why I avoid word processors. Which in turn reminded me just how awful the revision control is in most such software (generally some combination of painful and incomplete). So now I'm inspired to make a more general habit of developing documents under some degree of RCS/CVS style management. RCS is better, for stuff I'm writing, since it works in-place. CVS forces you to keep a repository lying around.

Getting farther afield, a usability expert holds forth on CMSs with some observations that could be handy to keep in mind on PageCaptain. And someday, I may do something like this with the navidation functions, if the app continues to grow.

Posted by mill1974 at 8:31 PM

October 26, 2004

PageCaptain Issues

It's been known for some time that the PageCapt code needs a major overhaul in one crucial area: getting item list data into the system. It doesn't matter all that much how it gets in; once a PDF or such is available, a competent computer jockey and a pile of scripts can make short work of normalizing the thing and converting it to useful data structures.

Having taken some time yesterday to learn Javascript (it's a very derivative language) I'm now thinking about this problem again.

A major lesson of the past couple of years, though, has been that an electronic copy of the list is never available in a timely fashion, and that not having the database available in that first crucial half-day greatly reduces its potential utility over the course of the hunt. So unless we can find a good source of much higher-quality scanning software than we generally have lying around, and given the amount of manpower in a team of decent size, several people have suggested that it might just be easiest to round up a half dozen people and type in it.

To do this without making people feel like they're being forced to work in the salt mines, you want the job to go quickly and smoothly, which particularly necessitates a system that infrequently breaks the rhythm of typing, and mostly takes care of formatting for the user. The general consensus has been that having a round-trip to the server, plus the attendant overhead of re-rendering a page, etc., would make entering item data one by one an excessively annoying task. Moreover, people don't like just being set down in front of a blank editor page and told to type the list in, and here's how we need you to format it. We can obviously do better than that.

Previously what this has suggested is a system where an array of, say, ten item entry forms is presented to the user, which can be filled in and submitted as a batch. But this is an obvious kludge, which poses some unnecessary stumbling blocks. Ten items is a lot of typing to lose if the window accidentally closes, or if the submit operation fails for some reason. There's no good reason to cut off the typist at ten, either, when they could probably work longer and faster if not interrupted. There are also locking issues if you have lots of people entering items at once. There will inevitably be some overlap, and you'd like people not to enter an item and then be told that someone else has gotten there first.

What this has led me to think in the past is that some kind of multi-threaded app is called for, which would be able to accept input in several windows, just requiring a TAB or similar keystroke to advance from one field to the next, and which could then handle the server update when finished while the user proceeds to enter the next item. But I realized yesterday that, in a Javascript program, each browser window behaves effectively as a separate thread.

The strategy I'm looking at now involves a simple single-item entry form with a lot of preloaded data behind the scenes, manipulated by a Javascript program, that spits off windows with item data for submission as the typist finishes entering them. The master window could then just present three basic elements: some instructions, the entry form, and a progress indicator.

Instructions are programmatically easy, but some thought will need to go into making them concise and non-distracting. The entry form will include boxes for the item number, description, scoring, category, and a guess at points. The last two need to be optional, as they ask for information that may not be easy to discern at the time of entry. Additionally, the background code should make an effort to fill in the points box based on the scoring string. For the progress indicator, I'm thinking of a small tabular structure with a cell for each item in the (eventual) list, which could be filled in as items are entered. Clicking on an empty cell would allow starting work at a new point in the list.

Ideally, the progress structure would be updated by the script running in the other window. For that matter, I'm wondering if there is a good way to open a third window that loads some normalized form of the list that can be read by a Javascript program traversing the document tree; it would then be possible to reload the list status, also in the background, without having a huge chunk of data to (not) render in the working window.

My major concern so far is that I haven't found any standardized documentation for the top-level window object in Javascript. I get the impression that it's one of those extensions that is widely supported but not standardized, which means that any solution I devise might wind up being unusable under IE. Not disastrous, but mildly inconvenient perhaps.

Posted by mill1974 at 10:57 AM

October 16, 2004

Resources for Ancient Roman Life

In relation to the potential NaNoWriMo project, there is a handy page of links posted here at about.com regarding life in the classical world, and this list on social aspects of the same.

So far, this site is proving a particulary useful overview, although I would still like a good old-fashioned biblography. The Ancient History Sourcebook provides some of what I'd like in this regard, but the number of broken links is frustrating. However, knowing the titles of some resources can lead to tracking them down with Google.

This gigantic listing of maps online could be a goldmine. An interesting resource in this vein is a hydrological cartographic history of Rome. That one actually came from this list. The Roman Gazetteer looks handy in this regard as well.

Still working on the characters and plot, though. Given that I am also concentrating on the Scavhunt judge application and some fellowship applications in November, this project may or may not actually get off the ground.

Posted by mill1974 at 1:16 PM

October 11, 2004

To-Do for Work

And while we're at it, here's what's on my plate for my actual job. (I suppose this would properly be filed under "need to do" instead of "want" as such.)


GRASP8: continued analysis of crossed Dragone system GRASP8: generate (Tom: parameters) and analyze gregorian Dragone system CODEV: (get it working) continue work on many-lens system


MSI application (due 15th) Health plan enrollment


NSF Fellowship application (Nov 30) Natl. Defence fellowship application (Jan 7) research Stanwood Johnston fellowship
Posted by mill1974 at 4:59 AM

October 7, 2004

Ongoing Affairs

As I mentioned to Sam, the roommate, my schedule requires me to set a structure, of sorts, to pursue projects of my own. Of late, they've been multiplying somewhat (hmm ... maybe a product of spending less time on Slashdot), so here we have a bit of a catalogue. May be updated as I think of additional things I'm working on, or to add links.


Physical Optics in Perl


EGAD Learn Hebrew Learn Arabic


Causus Belli / NaNoWriMo Live-Hacking Perl Music ScavHunt and ScavCode
Posted by mill1974 at 4:22 PM

September 14, 2004

Music Hacking - Observations

Recently, I got the feedback.pl 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 feedback.pl are actually intended for the language engine, to trigger simple.sc 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 3, 2004

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 feedback.pl -- 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 feedback.pl 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

August 29, 2004


Just a useful link that could help with Crystal's multiple-computer syndrome.

Synergy2 works on Win32, X11, and OSX, lets you move mouse and keyboard functions between computers a-la virtual desktops. One system runs a server, and events are tunnelled over the network. Slick.

Posted by mill1974 at 2:51 PM

August 27, 2004

Annoying Proprietary Software

Mostly, I use free software. Not just because I'm a cheapskate -- this would be a poor reason since, as a student, most of my software is given to me, anyway. I like that it works well, that it has a tendancy to interoperate well, and that I can see its innards and twiddle them as needed.

There are, however, a few proprietary packages that my work requires that I use. To varying degrees, this is annoying the crap out of me.

To wit, and in rough order of annoyance:

A "rich man's" mathematical data analysis language, for people who like the idea of Matlab but were really more comfortable with Fortran back in the 70s.

Gigantic function library, but I can do most anything it can, often faster, and usually with superior (in terms of control and flexibility) results, with some combination of Perl, PDL, and graphics kits like XMGrace or Gnuplot. Since I'm too lazy to grab links for all those, feel free to Google them.

Plus the fact that half the time when I start it up, I can't actually use it, because the license server says that too many people are using it already, really drives home the un-freedom of the whole thing. I shudder to think how much of our group's experience is tied up in IDL code.


Free student version of an extremely powerful physical optics package. The full thing costs $40,000 and change, so I don't see us springing for it in the immediate future.

Trouble is, the free version has some distinct limitations designed to induce you to open the wallet (or more likely, purchase order folder). For instance, models are artificially limited to two reflecting/scattering surfaces. Also, it only generally helps with our work, since it doesn't do refraction at all. Since our telescopes have lenses, this makes us somewhat uncomfortable. On a totally unrelated note, its data formats really show the Fortran under the hood, too.

I think it should be possible to implement the physical optics engine using PDL, so I printed out (and bound -- yes, I'm a freak, see below) the technical manual to learn how. If I have a really slow weekend in Israel, I may give it a try.


Ray optics package.

I have mostly praise for this thing, actually. It works quite well, once you get to know it, has powerful features arranged in a way that suggests a modicum of thought may have been involved in their planning, and provides an amazingly complete palette of functionality for designing and analyzing an optical system.

The drawback. Only runs on Windows. I kid you not. Used to be a UNIX version, but they killed it for reasons that baffle me, considering that nearly every scientific shop on the planet is mostly *nix workstations. So I'm stuck either remotely logging into a Microsoft box, or, as I will be in Israel, running one in emulation inside my own system. The cryptographic hardware key is just icing on the cake, there.

But the fact that I'm not actively thinking about how to reimplement this one using free technologies is evidence of just how good it is, otherwise.

Posted by mill1974 at 7:41 PM

Media and Software

Software is seductive. It has such potential to be useful.

Downhill Battle is an outfit looking to rewrite the rules of media culture, with the record label cartel particularly in their sights. The Labs will try to do this with software, by integrating the distributed collaborative nature of blog-like phenomena with new media distribution technology.

The AllAfrica Blogs is an aggregator of Africa-based blogs, in an attempt to inject the developing world into that of the predominantly wealthy, Caucasian digerati. Probably more on this another time.

And the banal (and tangentially related): the kernel hacker in charge of the PWC driver that runs Phillips webcams has thrown a hissy fit over kernel binary module policy and withdrawn his driver. While it is evidently his intention to take the ball home, the practical effect is simply that a new maintainer is needed (looks like the guys using Lava Lamps as RNGs are stepping up on that). Behold the world's easiest entry to Linux kernel developer status.

Posted by mill1974 at 7:06 PM