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.)

Computations

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

Beaurocracy

MSI application (due 15th) Health plan enrollment

Funding

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

October 9, 2004

MDT

On this week's Tangled Bank we find an Introduction to Multiple Designers Theory, an attempt by one Richard Hoppe to inject some scientific method into the ID scrum.

I suppose my initial, visceral reaction to reading it is some displeasure at the fact that, given the intent of the effort, the best he can do towards fabricating a real academic discipline out of ID is to reduce evolutionary biology to something like art history. More substantively, I detect two areas of intellectual sloppiness; I'm not sure to what extent I should blame this on Hoppe, and to what extent I am simply reading unfairly based on my admittedly sparse experience with current ID writing (I hesitate to call it "scholarship").

The first is the insistence on an "unembodied" set of designers. I understand that this would be absolutely vital if one tried to postulate that intelligent design is an ongoing process, effectuating biological change from one generation to the next in a broad class of organisms -- there is no reasonable method by which some intelligent, physical entities could access and alter so many pieces of matter, in so many locations, without someone noticing. Not unless there is some heretofore-unrecognized variety of intelligent virus, which would run into severe information theory difficulties. However, if one already concedes that design is an activity that can take place in punctuated bursts, at various times during the Earth's history, then there seems to be no reason why physical designers are ruled out, so long as no widespread instance of design has taken place since humans became globally dispersed and keepers of accurate observational records -- which is to say, not in the past millenium or so. If designers are inclined to work in more geographically localized domains, however, who's to say that it isn't ongoing somewhere on Earth that we simply haven't noticed.

Moreover, the appeal to one or more "unembodied" designer entities raises the serious question of physical mechanism. The "infinite wavelength-zero energy" proposal raised in this article falls somewhere between mumbo-jumbo and nonsense. The author suggests that MDT research need not concern itself immediately with the mechanism by which the design activity occurs. This is fine, if a tad incurious, but proves that there is no crisis of understanding connected to this mechanism question, only a lack of data. If there isn't an extremely good reason to require such noncorporeal beings, Occam's razor alone strongly militates against them, and good sense likewise advises against inventing new physics to explain a phenomenon the existence of which your theory is indifferent towards.

The second objection, stemming from the first, is that no mention is made of conventional evolution taking place in tandem with designed processes. There is a wealth of evidence that selective mutation-driven evolution can account for some, if not all, of the biological diversity currenlty observed, and plenty more data support the proposition that this mechanism is ongoing. Therefore, and especially if one posits punctuated design, it seems vital to include "mechanistic" evolution alongside the intelligent process.

With regards to this second point, I may be simply misunderstanding ID theory as it currently stands. It could be the case that the ID crew implicitly assumes that conventional evolution does take place, and thus never mentions it. Indeed, the presently ubiquitous notion of "irreducible complexity" would seem to concede that evolution works just fine, except for the genesis of those features judged to be "irreducibly" complex.

One reason that I am somewhat intrigued by MDT is that it offers a potentially coherent line of investigative activity that would, if pursued, validate it as a true empirical science. So long as the ID community declines to take this bait, it gives me an exceedingly handy piece of ammunition against the creationist hecklers that keep showing up to astronomy outreach events. It becomes a perfectly valid question to ask, then, why if evolution is so obviously deficient, are no ID proponents actively researching the one area of ID thought so far to suggest a realistic research programme.

Another aspect is that MDT, preferably with punctuated design and physical, "embodied" designers, offers some insight into Fermi's paradox. Namely, the evidence for biological design in the Earth's past would, if confirmed, represent the strongest support yet for the "They are already here" solution to the paradox. This could, likewise, help move the SETI research program toward some actual conclusions, by posing questions grounded in fact instead of conjecture. Questions like, "Now that we know someone was here, where did they go?"

Posted by mill1974 at 1:26 PM

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.

Work-related

Physical Optics in Perl

Location-related

EGAD Learn Hebrew Learn Arabic

Ongoing

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