It was a new job, or rather a reenactment of one from ages past. She was a sort of anti-"yes man", mocking the managers of the company and stirring up trouble, protected by the CEO. From unpointed, simply amusing songs to long parodies of the corporate attitude, she performed for the board, the president, and the CEO. She felt awkward, but her whole life had been somewhat awkward since she entered university, and double majored in theatre and business. She could never explain her job to her friends, as when she tried, she found the concept again so ludicrous that she broke into a mix of laughter and tears. Today, she was just gathering intelligence, "hanging out" around one of the project managers, trying to decide how to convey impressions in Friday's meeting with the board. A modern day court jester.

I recently had raised the prospects of going to CMU-Qatar, and talked with some of the HR people about the details. Of course, the devil's in the details, and there are a few good reasons not to go that I asked about and found. I'm currently chewing things over, trying to decide if these reasons are important enough to stop me from going.

At work, I'm rerunning a very old analysis, and am discovering reasons for some of the odder flags we have in some of our analysis software. Apparently, a number of brains we got then were, for some reason, given to us upside down. I hope that none of them have left-right swapped -- it's not so easy to spot that by eye, and I wasn't looking for it. I sometimes am amazed that our grouptransform software does as good a job as it does with some of the brains we get. For those not involved in neural imaging, here's how we analyse a brain, in brief.

1. We have two different kinds of scans, a high resolution structural scan, and a large set of lower resolution functional scans. Each of them comes to us as a large number of Dicom files, each representing a single slice of the brain (usually 34 slices covers the entire brian). A single DCM file might be 64x64 for a functional or 256x256 for a structural.
2. We convert the DCMs into a different format called Analyse. Analyse files each compose an entire scan (brain image), so we end up with a single structural analyse file, and a lot (one for every 2 seconds) of functional files. In my current study, I have 2100 functional files per run of a subject.
3. We do motion correction over the functionals to correct for small movements of a subject in the scanner.
4. We then do group transformation, using the structural images and a reference brain to build transformation maps to alter all the functional images into the brainspace of our standard brain
5. We then have what we'd like to assume would be a lot of brain data that's in the same subject-physical space that lets us analyse over other factors (still including per-subject "software" factors) in a number of analyses.

There's a lot of room for potential problems along the process -- the grouptransform seems most problematic to me, because the kind of transformations the software can make are all fairly primitive, and none of them are aware of inner structure of the brain (with the algorithms involved, you might as well be transforming a cat's face into another cat's face). Oddly, it generally works out pretty well if you keep an eye on it. There's a lot of interest in the community for smarter grouptransforms, although most of this focuses on better base transformations being possible instead of bring aware of brain features. I've been trying to decide if any of the software my old group in robotics might be suitable -- I might go explain the problem to my old boss and see if any interesting ideas could pop up on how to do it better.

And now, the news..

In Persia, the presidential elections are going to run-off, having failed to give any single candicate much more than 20 percent of the vote. I'm not sure why I find persian politics so interesting -- perhaps it's that their form of government is, so far as I know, quite novel.

China is coming to terms with rampant pollution -- they note that their population is more than double it was when the revolution happened, but environmental damage has reduced the livable land to about half what it was.

Microsoft is making a shot at designing a better shell. Their shell is called Monad shell, and they're hoping to make a better shell design than Unix. Looking over the ideas they're implementing, a lot of the capabilities they tout as being better than Unix are, in fact, possible within the Unix architecture, but are not actually commonly done by Unix software. One particular example is passing objects that have their own embedded methods around -- the same effect could be achieved by passing XML streams that have references to programs or raw script data enclosed for manipulating the actual data. It's not hard, but part of the Unix philosophy is that you can hook anything up to anything and it's your responsibility, as the shell user, to make sure that what you do makes sense. It's a more freeform environment than MSH is likely to be, which has its advantages and disadvantages. Monad will be interesting to play with. I don't think it'll be easy to change Unix to compete in any greater sense, because the way shells and programs interact is foundational to Unix in the same way that the Windows APIs are foundational to Windows. One thing I've always wanted in Unix is tab-completion that's aware of the options of the programs being invoked. This, unfortunately, would require a standard hook in all commandline utilities that the shell could invoke to learn about options. It may be possible to do this with GNU getopt, which actually might be an interesting project, as a fair number of projects use getopt, and several others may be persuaded to migrate to it if it provides a feature users want.