I admit to not reading a lot of nonfiction, especially if it is unrelated to my career. But recently, when I was dragged to a *-Mart, the cover, title, reviews, and introduction of Freakonomics pulled me in, hard. Merely the book's approach, applying the data mining and incentive-based reasoning of economics, intrigued me, let alone the colorfulness of the topics and conclusions. And I think it should go without saying that rethinking old assumptions through a high-level, objective analysis is a worthy goal, at least for anyone seeking the whole truth.
On the other hand, I can also see some weaknesses here. First of all, the reliance on statistics, while being the foundation of the book's claimed authority, can make for dubious evidence. There are three kinds of lies: lies, damned lies, and statistics. Dizzyingly intricate data manipulation can certainly illuminate patterns in a particular sample, but the more the data must be "massaged" and interpreted to reach an answer, the less convincing the evidence becomes. Second, the disagreements between economists when discussing even their own subject matter don't inspire confidence in bringing other topics under the same treatment. To be fair, their attempts to decipher the behavior of something as mind-bogglingly complex as the economy are admirable. It is unfortunate that they can't rely on direct experimentation the way that sciences, such as psychology, can.
Third, their picture of humanity is, of course, simplified. As others on the Web have commented, this book's subject matter is more like that of sociology and psychology than traditional economics. As I understand it, economics treats people as rational agents who balance their decisions in order to maximize profit and minimize cost. (I'm reminded of some comments that Yul, the last Survivor winner, made about one of his competitors, Jonathan. Yul said that he could predict Jonathon's actions simply because Jonathon was a rational player out to win the game for himself. In this sense, Yul was thinking like an economist.) This model assumes a competition is in place for the available payoffs, but there are other ways that people interact, such as sharing, collusion, or the extreme opposite: self-sacrifice. Sociologists would place greater emphasis on these other modes. The economic view would fit with the idea of government being a "social contract" in which free citizens cede some powers in order to have other needs filled.
The book acknowledges this third weakness, by describing social and moral "incentives" (so it's more blessed to give than receive only because the giving act benefits the giver in some way?). Essentially, the economic model of human behavior is not falsifiable. If people act to gain positive incentives and reject negative incentives, then an incomplete analysis of any given situation indicates that the analyst needs to consider more incentives. Funny thing is, I'm pretty sure I've encountered this idea before: radical behaviorism. Push a lever, get a fish biscuit. The fiction book Walden Two presented a utopia brought about with those methods. In case it's not clear, I find that philosophy highly distasteful. Higher brain functions are A Good Thing.
Freakonomics doesn't duck such objections. It invites them. In fact, one of the points made by the book is that the decision to cheat or steal, i.e. breaking rules in order to obtain a resource, is like any other (economic) decision: it simply has strongly negative social and moral incentives. Since everyone acts economically, therefore most everyone cheats, but only when it makes (economic) sense. For instance, when the negative social incentive is infinitesimal because of an infinitesimal chance of being caught, or the negative moral incentive is puny because the otherwise rightful resource holder can "afford" to not have it. Truly, someone must have a firm, crunchy moral center indeed to turn down those opportunities. Or someone can try to engineer additional incentives against cheating, like the designers of Walden Two. It may be true that most people have moral limits, and "every man has his price", but that doesn't mean I must like it or condone it. A utopia would work well, if we could only manage to get around the people problem.
Thursday, December 28, 2006
Monday, December 18, 2006
relational database as inference engine
A short while ago, I was reworking an SQL query to ensure that it would yield the precise results the rest of the application expected. (Side observation: my conscience kept hollering at me to make the SQL simpler and just crunch the returned data as needed. Shut up, Jiminy! Go spell encyclopedia and leave me alone.) I noticed that I was adding, taking away, and rearranging WHERE conditions to match particular rows. But matching to specific data based on a generalized set of characteristics is also an activity performed by inference engines! It's not that far of a leap to equate database rows to facts, SQL queries to rules, and newly-inserted database rows to concluded facts or assertions. I wouldn't be surprised if the academics in these two camps have been cross-pollinating ideas for some time. If I knew substantially more than jack about real relational database theory, I could offer some insightful comments. Instead, here's an example.
Imagine a set of widgets available for sale. A white widget has no additional cost, a black widget costs an additional 400, and a green widget costs an additional 200. The base cost for round widgets are 100, square widgets are 200, and triangular widgets are 150. How much does a round, black widget cost? An inference engine might have the set of rules (color white) => add 0, (color black) => add 400, (color green) => add 200, (shape round) => set 100, (shape square) => set 200, (shape triangle) => set 150. Then one could add the facts (color black) and (shape round) and have the answer. Or at least the necessary addends.
A (SQL-compatible) database could do a similar operation. One particular combination (or should I say tuple?) of facts becomes a row in table "facts". The rules become: (select 0 from facts where color = "white"), (select 400 from facts where color = "black"), (select 200 from facts where color = "green"), (select 100 from facts where shape = "round"), (select 200 from facts where shape = "square"), (select 150 from facts where shape = "triangle"). Add a row to "facts" that has a "color" column of "black" and a "shape" column of "round", run the queries, and there's your answer. Or at least the necessary addends.
The similarities become more striking when you use a database table in the usual way, i.e., using a row to represent one member out of a collection of similar entities. To refer back to the previous example, this just means renaming the "facts" table to "widgets" and breaking non-widget facts out into separate tables (the usual normalization). SQL queries that match multiple entities at once will employ JOINs. In the inference engine, an entity would look like (widget (shape square) (color green)), and I assume that rules that match multiple entities would work about the same as rules that match multiple individual facts.
As to whether it makes practical sense to map a relational database to an inference engine or vice versa, I'm inclined to think not. If your problem domain is rigid enough to work in a database, then there's no gain in using an inference engine instead. If your problem domain is a classic example of AI, a rather fuzzy attempt to capture a variety of heuristics working on loosely-structured data, then the database details would bog you down. To say nothing of the limitations (and proper place) of SQL.
Imagine a set of widgets available for sale. A white widget has no additional cost, a black widget costs an additional 400, and a green widget costs an additional 200. The base cost for round widgets are 100, square widgets are 200, and triangular widgets are 150. How much does a round, black widget cost? An inference engine might have the set of rules (color white) => add 0, (color black) => add 400, (color green) => add 200, (shape round) => set 100, (shape square) => set 200, (shape triangle) => set 150. Then one could add the facts (color black) and (shape round) and have the answer. Or at least the necessary addends.
A (SQL-compatible) database could do a similar operation. One particular combination (or should I say tuple?) of facts becomes a row in table "facts". The rules become: (select 0 from facts where color = "white"), (select 400 from facts where color = "black"), (select 200 from facts where color = "green"), (select 100 from facts where shape = "round"), (select 200 from facts where shape = "square"), (select 150 from facts where shape = "triangle"). Add a row to "facts" that has a "color" column of "black" and a "shape" column of "round", run the queries, and there's your answer. Or at least the necessary addends.
The similarities become more striking when you use a database table in the usual way, i.e., using a row to represent one member out of a collection of similar entities. To refer back to the previous example, this just means renaming the "facts" table to "widgets" and breaking non-widget facts out into separate tables (the usual normalization). SQL queries that match multiple entities at once will employ JOINs. In the inference engine, an entity would look like (widget (shape square) (color green)), and I assume that rules that match multiple entities would work about the same as rules that match multiple individual facts.
As to whether it makes practical sense to map a relational database to an inference engine or vice versa, I'm inclined to think not. If your problem domain is rigid enough to work in a database, then there's no gain in using an inference engine instead. If your problem domain is a classic example of AI, a rather fuzzy attempt to capture a variety of heuristics working on loosely-structured data, then the database details would bog you down. To say nothing of the limitations (and proper place) of SQL.
Thursday, December 14, 2006
arithmetic unplugged - the abacus
Somewhere in the intersection of the sets "unnecessary activies", "math-related stuff", "exotic devices", "cheap equipment", and "skills requiring long practice" is "the use of an abacus". How could a frugal ComSci-major/Math-minor with way too much time on his hands resist?
I bought a surprisingly little but quite usable 13-rod Japanese abacus or soroban on eBay for cheap, and also an old but lightly used copy of The Japanese Abacus: Its Use and Theory by Takashi Kojima (ISBN 0-8048-0278-5, although I later stumbled on a page with links to a verrrrry similar pdf). If I had the requisite desire and/or discipline I would probably be pretty good at using my soroban--I'm not. Part of the lack of motivation stems from the fact that I have no practical reason for improvement; after all my cell phone (the same one that once made me feel like I had the power of the sun in the palm of my hand) has a calculator function. Nevertheless, I'm progressing slowly.
On the soroban, each rod has one 5-unit bead and four 1-unit beads, with a separator between the fiver and the rest. This means that the soroban is primarily for regular decimal-based applications, although I suppose one could use just the 5-beads and do binary math if one wanted to (setting the 5-bead would represent a 1, and each rod would represent a power of two). Note that more than 6 or so items in a group could be hard to accurately recognize and distinguish at a glance, so more beads might actually make calculations slower, because it would force the operator to laboriously count bead-by-bead.
One exceedingly simple drill for beginners, that I haven't seen mentioned anywhere, is just to add a single-digit number to itself a set number of times. It's easy to tell when you've made a mistake: merely check to see if the result is a multiple of the number. You can also start with a high multiple and perform a series of subtractions. The point of this drill, which clearly would never be performed with an abacus in a real situation, is to increase your speed. In my opinion, it makes sense to get really good at this drill before adding and subtracting two digit numbers, which seem to be the usual starting exercises for the abacus.
As the little book explained, the abacus procedures simplify a calculation by breaking it up into lots of rapid, little single-digit calculations. The usual pencil-and-paper method is almost exactly like the abacus method (in spirit anyway), but with some significant differences. The first, of course, being that the paper method involves writing a problem out, while an abacus operator just flicks his fingers to shift some beads--a considerably simpler if not faster motion. The second difference is that numbers in the paper method are distinguished by having differently shaped symbols, while numbers on an abacus are actual quantities of beads--numbers you can feel. Hence the usefulness of the "toy" abacus in teaching children.
The third and most confusing difference is that the paper method is free-form or malleable, while an abacus cannot be "rewritten" to have more or less beads in any given case! On the abacus, "carrying" and "borrowing", meaning the overflow or underflow of one power of ten to another, are achieved by making a one-bead adjustment in the higher power and then offsetting that adjustment by moving beads in an inverse operation in the lower power. You undo the excess. For instance, to add 4 to 8, you:
The freaky conclusion of abacus training is the operator becoming able to do abacus manipulations on an imaginary abacus, enabling savant-like mental calculation. I don't plan to reach that point for a looooong time, but here is an incredible account that I'm not sure I believe. If the story's completely true, I might like to hire him as my mentat (I'll get that Leto!). Here are some of the more useful links I've found.
I bought a surprisingly little but quite usable 13-rod Japanese abacus or soroban on eBay for cheap, and also an old but lightly used copy of The Japanese Abacus: Its Use and Theory by Takashi Kojima (ISBN 0-8048-0278-5, although I later stumbled on a page with links to a verrrrry similar pdf). If I had the requisite desire and/or discipline I would probably be pretty good at using my soroban--I'm not. Part of the lack of motivation stems from the fact that I have no practical reason for improvement; after all my cell phone (the same one that once made me feel like I had the power of the sun in the palm of my hand) has a calculator function. Nevertheless, I'm progressing slowly.
On the soroban, each rod has one 5-unit bead and four 1-unit beads, with a separator between the fiver and the rest. This means that the soroban is primarily for regular decimal-based applications, although I suppose one could use just the 5-beads and do binary math if one wanted to (setting the 5-bead would represent a 1, and each rod would represent a power of two). Note that more than 6 or so items in a group could be hard to accurately recognize and distinguish at a glance, so more beads might actually make calculations slower, because it would force the operator to laboriously count bead-by-bead.
One exceedingly simple drill for beginners, that I haven't seen mentioned anywhere, is just to add a single-digit number to itself a set number of times. It's easy to tell when you've made a mistake: merely check to see if the result is a multiple of the number. You can also start with a high multiple and perform a series of subtractions. The point of this drill, which clearly would never be performed with an abacus in a real situation, is to increase your speed. In my opinion, it makes sense to get really good at this drill before adding and subtracting two digit numbers, which seem to be the usual starting exercises for the abacus.
As the little book explained, the abacus procedures simplify a calculation by breaking it up into lots of rapid, little single-digit calculations. The usual pencil-and-paper method is almost exactly like the abacus method (in spirit anyway), but with some significant differences. The first, of course, being that the paper method involves writing a problem out, while an abacus operator just flicks his fingers to shift some beads--a considerably simpler if not faster motion. The second difference is that numbers in the paper method are distinguished by having differently shaped symbols, while numbers on an abacus are actual quantities of beads--numbers you can feel. Hence the usefulness of the "toy" abacus in teaching children.
The third and most confusing difference is that the paper method is free-form or malleable, while an abacus cannot be "rewritten" to have more or less beads in any given case! On the abacus, "carrying" and "borrowing", meaning the overflow or underflow of one power of ten to another, are achieved by making a one-bead adjustment in the higher power and then offsetting that adjustment by moving beads in an inverse operation in the lower power. You undo the excess. For instance, to add 4 to 8, you:
- Check to see if you have enough beads on the rod under consideration. Since there is only one 1-bead left (8 is one 5-bead and three 1-beads), proceed to step 2.
- In step 3, you will add a 1-bead on the tens rod to the left, which will be too much by 10 - 4 = 6. So reset six beads, that is, the 5-bead and one 1-bead, leaving two 1-beads.
- Add the 1-bead in the tens rod. By not doing this until last, you can keep your attention on the unit rod for both steps 1 and 2. Otherwise, you would focus on the unit rod, switch to the tens rod, then switch back to the unit rod to undo the excess.
The freaky conclusion of abacus training is the operator becoming able to do abacus manipulations on an imaginary abacus, enabling savant-like mental calculation. I don't plan to reach that point for a looooong time, but here is an incredible account that I'm not sure I believe. If the story's completely true, I might like to hire him as my mentat (I'll get that Leto!). Here are some of the more useful links I've found.
- The Abacist's Guide to the Internet. Nice page o' links.
- Another page o' links.
- Some stories about learning the abacus.
- Article about nonelectric calculating. It includes specific details and information about the soroban.
- A different soroban manual. Very good, with step-by-step instructions and many pictures. On par with the book I bought, and probably even has an edge in ease of understanding. On the other hand, I wanted the convenience, guidance, and earthiness of a book as I learned. Using the computer to learn the abacus also felt heretical...
Friday, December 01, 2006
If House visited Scrubs
I regularly watch House and Scrubs. Both shows take place mostly in hospitals, but Scrubs is more likely to have scenes elsewhere. Scrubs seems to have more minor and recurring characters than House, which mostly revolves around a few people (the Simpsons has far more than both put together, but since tremendously talented voice actors can do multiple cartoon characters this is no surprise). House is about complicated diagnoses; it's the medical equivalent of a mystery or "whodunit", while Scrubs is more about the daily and routine trials of hospital work. House is a drama that often has (acerbic) funny moments. Scrubs is more of a comedy with token dramatic moments. Scrubs has its share (or more) of shmaltz, but House is more stingy in that regard. Most prominent of all, in my opinion, is that House takes place in a realistic setting, and Scrubs takes place in a surreal setting (including J.D.'s imaginative mind).
What I find fascinating is the huge contrast in tone. Consider this thought experiment or scenario: J.D. can't figure out what's wrong with a patient. He calls Dr. Cox. After calling J.D. Rhonda and launching into a drawn-out tirade about how he isn't a genie to be summoned at will by the incompetent, Dr. Cox decides to bring in the renowned Dr. House. Dr. Kelso meets Dr. House at the door, smiling widely and generally trying to flex his political know-how. House nods politely until Kelso is done talking, then nails him with a surgically-precise insult. Dr. Kelso raises an eyebrow in surprise that someone stood up to him so well, then walks away in a huff. If J.D. watched this exchange, then there may have been a daydream sequence in which House and Kelso fought in a Western quick-draw gun duel. When House arrives at the patient's bed to deliver his first cynical comment about the root cause, the patient immediately starts convulsing and coughing up blood, because that's what House's patients do. Carla stabilizes the patient with her usual quick action. When House orders her to perform a painful test, she flatly refuses before giving House unsolicited advice on his lack of caring. House gives the standard retort that "all he's trying to do is save the patient's life", to which Carla responds by telling House to do it himself. If the test is highly expensive, House may also need to cajole Dr. Kelso into allowing it at all. Later, House concludes that some surgery is needed, so Turk comes by to receive instructions. In the ensuing conversation, House makes a racial joke, but it flies completely over Turk's head. At meal time, House sits with Dr. Cox to fill him in on his diagnosis so far. He starts by making a poor analogy, then waiting for Cox to ponder what he's saying. Cox makes his own poor analogy between doctors who don't say what they mean and women with deceptive breast implants. House mocks Cox for being so slow, and Cox mocks House for treating his work like a game. Eventually they manage to communicate. Towards the end, Jordan joins Cox at the table. House includes her by indulging in some thinly-veiled innuendo. Jordan not only fails to be embarrased by this, but follows it up by insulting House's masculinity in some way. As all this is going on, there is a subplot involving J.D. and Elliot, but nobody cares because the guest star is more fun. In the end, the patient may or may not die because this is Scrubs, but in any case it won't be because House was wrong. With well-hidden enthusiasm, House will leave, overjoyed to return to a hospital where people take things, such as Dr. House, more seriously.
What I find fascinating is the huge contrast in tone. Consider this thought experiment or scenario: J.D. can't figure out what's wrong with a patient. He calls Dr. Cox. After calling J.D. Rhonda and launching into a drawn-out tirade about how he isn't a genie to be summoned at will by the incompetent, Dr. Cox decides to bring in the renowned Dr. House. Dr. Kelso meets Dr. House at the door, smiling widely and generally trying to flex his political know-how. House nods politely until Kelso is done talking, then nails him with a surgically-precise insult. Dr. Kelso raises an eyebrow in surprise that someone stood up to him so well, then walks away in a huff. If J.D. watched this exchange, then there may have been a daydream sequence in which House and Kelso fought in a Western quick-draw gun duel. When House arrives at the patient's bed to deliver his first cynical comment about the root cause, the patient immediately starts convulsing and coughing up blood, because that's what House's patients do. Carla stabilizes the patient with her usual quick action. When House orders her to perform a painful test, she flatly refuses before giving House unsolicited advice on his lack of caring. House gives the standard retort that "all he's trying to do is save the patient's life", to which Carla responds by telling House to do it himself. If the test is highly expensive, House may also need to cajole Dr. Kelso into allowing it at all. Later, House concludes that some surgery is needed, so Turk comes by to receive instructions. In the ensuing conversation, House makes a racial joke, but it flies completely over Turk's head. At meal time, House sits with Dr. Cox to fill him in on his diagnosis so far. He starts by making a poor analogy, then waiting for Cox to ponder what he's saying. Cox makes his own poor analogy between doctors who don't say what they mean and women with deceptive breast implants. House mocks Cox for being so slow, and Cox mocks House for treating his work like a game. Eventually they manage to communicate. Towards the end, Jordan joins Cox at the table. House includes her by indulging in some thinly-veiled innuendo. Jordan not only fails to be embarrased by this, but follows it up by insulting House's masculinity in some way. As all this is going on, there is a subplot involving J.D. and Elliot, but nobody cares because the guest star is more fun. In the end, the patient may or may not die because this is Scrubs, but in any case it won't be because House was wrong. With well-hidden enthusiasm, House will leave, overjoyed to return to a hospital where people take things, such as Dr. House, more seriously.
Sunday, November 26, 2006
peeve no. 244 is breaking upgrades
Preface: I'm a little hesitant of embarking on this rant, because I'm fully aware that I may come out looking like an imbecile, n00b, or [insert preferred term of mockery here]. But then I remember that a written rant is the thinking's man version of a gorilla tantrum, so any ranting doesn't flatter me anyway.
Until a few days ago, I was running Debian testing ("etch"--kudos on trying to get the next release out sooner). Well...more or less. My installation started out quite a while ago as Mepis, but over time I replaced almost everything with plain Debian. I used some packages from Debian unstable (Sid) here and there. Then I read that many users run the unstable distribution, it doesn't break as much as you might think, it always has the latest and greatest, it's not quite as frozen as testing close to a release...so I pointed my apt to pure unstable (can you guess where this is going?).
I upgraded a few of the packages I care about most and enjoyed the new features. Then I saw an upgrade that required udev...one of those "program A depends on framework B depends on infrastructure C" cases that make me glad for automatic dependency handling. I was running hotplug, because that was part of the initial install (the kernel was a distro-patched version 2.6.12, I believe). I waited until I had a lengthy, contiguous block of time, and let the upgrade happen. Oooops. The udev package made it very clear that it wanted to run on a later kernel. This might faze some folks, but kernel shlepping is not new to me considering I ran Gentoo back before it offered any precompiled kernel at all, so I installed the Debian meta-package that depends on the latest kernel, made sure the necessary bits were in my grub config, and rebooted.
This wouldn't be a rant if it had worked. The kernel ran through the boot process, appeared to load the modules it should, and started executing items in the initrd. End result: something similar to "can't mount /dev/hdb3 on /". The filesystem on that partition is ext3! I started to feel the primal rage that comes on whenever, from my perspective, software refuses to do as it's told. I rebooted back into the other kernel. I searched the Web for similar troubles. I'm inclined to blame udev for not doing its job, or maybe the initrd creation tool. I fell into a cycle of fiddling with the packager or rerunning a tool, rebooting, calling out dirty names, and repeating the process. After I had enough, I decided to admit I had no clue what the cause was. Some unknown magic smoke on my system wasn't magically smoking like it should. I was desperate. My new kernel couldn't even get me to a real shell. I humbled myself before apt, and upgraded the world.
Afterwards, the new kernel still wouldn't boot, the old kernel booted and initialized fine, and pretty much everything in userland was down for the count. No X, no network access...now a broken guy with a broken system, I copied the important stuff on my / partition to my home partition, tossed in one of my LiveCDs long enough to download and burn an iso, and then installed Ubuntu. I have vowed to confine my repository list to the basics, because breaking updates suck huge donkey balls. Apologies for any unpleasant mental images.
Bonus rants: It's been an interesting change going from Konquerer to Nautilus (is it still called Nautilus?), amaroK to rhythmbox, kwm to Metacity. Here are my complaints:
Until a few days ago, I was running Debian testing ("etch"--kudos on trying to get the next release out sooner). Well...more or less. My installation started out quite a while ago as Mepis, but over time I replaced almost everything with plain Debian. I used some packages from Debian unstable (Sid) here and there. Then I read that many users run the unstable distribution, it doesn't break as much as you might think, it always has the latest and greatest, it's not quite as frozen as testing close to a release...so I pointed my apt to pure unstable (can you guess where this is going?).
I upgraded a few of the packages I care about most and enjoyed the new features. Then I saw an upgrade that required udev...one of those "program A depends on framework B depends on infrastructure C" cases that make me glad for automatic dependency handling. I was running hotplug, because that was part of the initial install (the kernel was a distro-patched version 2.6.12, I believe). I waited until I had a lengthy, contiguous block of time, and let the upgrade happen. Oooops. The udev package made it very clear that it wanted to run on a later kernel. This might faze some folks, but kernel shlepping is not new to me considering I ran Gentoo back before it offered any precompiled kernel at all, so I installed the Debian meta-package that depends on the latest kernel, made sure the necessary bits were in my grub config, and rebooted.
This wouldn't be a rant if it had worked. The kernel ran through the boot process, appeared to load the modules it should, and started executing items in the initrd. End result: something similar to "can't mount /dev/hdb3 on /". The filesystem on that partition is ext3! I started to feel the primal rage that comes on whenever, from my perspective, software refuses to do as it's told. I rebooted back into the other kernel. I searched the Web for similar troubles. I'm inclined to blame udev for not doing its job, or maybe the initrd creation tool. I fell into a cycle of fiddling with the packager or rerunning a tool, rebooting, calling out dirty names, and repeating the process. After I had enough, I decided to admit I had no clue what the cause was. Some unknown magic smoke on my system wasn't magically smoking like it should. I was desperate. My new kernel couldn't even get me to a real shell. I humbled myself before apt, and upgraded the world.
Afterwards, the new kernel still wouldn't boot, the old kernel booted and initialized fine, and pretty much everything in userland was down for the count. No X, no network access...now a broken guy with a broken system, I copied the important stuff on my / partition to my home partition, tossed in one of my LiveCDs long enough to download and burn an iso, and then installed Ubuntu. I have vowed to confine my repository list to the basics, because breaking updates suck huge donkey balls. Apologies for any unpleasant mental images.
Bonus rants: It's been an interesting change going from Konquerer to Nautilus (is it still called Nautilus?), amaroK to rhythmbox, kwm to Metacity. Here are my complaints:
- The volume/mixer applet for the KDE panel showed levels for several outputs, and I could adjust one of the levels just by clicking or dragging the level bar in the panel. The Gnome applet appears to require clicking on the icon, waiting until a slider pops up, then moving it. And if you want to change something other than Master, double-click it to get a complete set of sliders.
- amaroK's panel icon dynamically changed as the current track progressed. So a quick glance at the icon was sufficient to tell how far in the track was. You don't miss this feature until you've had it and then been without it. It would also be nice if rhythmbox had the "stop after playing the current track" command that amaroK has.
- In KDE, I could assign a permanent keyboard shortcut to a window. For instance, I could assign a shortcut to my browser window on desktop three, a different shortcut to amaroK on desktop one, and switch from one to the other with a single multi-key combination. (I like to use the "Win" keys for this purpose). Gnome has a window-selector panel applet that pops up a list of all open windows (Alt-Tab merely cycles between windows on the current desktop) on click, but that requires mousing over and clicking on the applet, scanning the window list, and clicking on the desired window. When I was going through my minimalist phase (on Gentoo), I could use and assign keyboard shortcuts for what seemed like everything in IceWM (don't mention Fluxbox, I'll slug you). Surely Metacity can do the same?
Tuesday, November 21, 2006
subjective impressions of Objective-C
After I read a comment on some blog expressing high praise for the features of Objective-C, I've been going through some introductory materials found by Google. I must say that the experience has been eerie. It's almost as if someone was storing C and Smalltalk on the same volume, there was some corruption, and the recovered file(s) ended up mashed together. I confess to knowing about as much about Smalltalk as Objective-C (that is, close to nil - HA, I made a funny!), but the resemblance is obvious. I think I have a clearer understanding of how people can assert() that Java is C++ going back to its Smalltalk roots, but not quite getting there.
First, the parts I like. The Categories capability is intriguing. It reminds me of the roles that are part of Perl 6. I also like the choices the language offers: either use objects with a type of "id" and send messages to whatever object you like, or use static object types and Protocols when that level of dynamic behavior is undesireable or unnecessary. Even better, Objective-C inherits the high-performing "close-to-the-metal" compilation of C, with an extra library that handles the fancy object tricks at runtime. I kept wondering why I hadn't heard more about this language, and why it didn't seem to be in more widespread use (by the way, I own nothing made by Apple).
Then my reading uncovered several justifiable reasons why Objective-C didn't hit the big time, at least on the scale of Java or C++. It doesn't have a true standard, which means that the chance of multiple entities implementing it is correspondingly lower. On the other hand, one open implementation can act as a de facto standard, so this criticism may not apply to GNUstep. Another problem for me is the syntax. Punctuation ([ : - +) is used in ways that I've never seen before. Perl is worse in this way, and I suppose that programmers who seriously use Objective-C become accustomed. Something else that bugs me is Objective-C's strong association with specific framework(s). A standard library is fine, of course, in order for a language to be useful, but I expect there to be competing libraries or toolkits for anything more complicated. I also wish that Objective-C was implemented on a common platform (Parrot, CLR, JVM), which would get rid of this issue. But then Objective-C would be competing with languages that have dynamically-typed OO as well as convenient syntax niceties that elevate the programmer above C's level. Frankly, although Objective-C is fascinating to study, I don't think it fits any important niches anymore, except possibly the niche currently occupied by C++. If you need Smalltalk-like abilities, use Smalltalk. If you just want to crunch numbers or strings at a high level of abstraction, use OCaml or Haskell. If you deeply need code that performs well, use C with a good compiler or even assembly. If you just need to solve a common problem, use a scripting language.
Here are some of the links I found:
First, the parts I like. The Categories capability is intriguing. It reminds me of the roles that are part of Perl 6. I also like the choices the language offers: either use objects with a type of "id" and send messages to whatever object you like, or use static object types and Protocols when that level of dynamic behavior is undesireable or unnecessary. Even better, Objective-C inherits the high-performing "close-to-the-metal" compilation of C, with an extra library that handles the fancy object tricks at runtime. I kept wondering why I hadn't heard more about this language, and why it didn't seem to be in more widespread use (by the way, I own nothing made by Apple).
Then my reading uncovered several justifiable reasons why Objective-C didn't hit the big time, at least on the scale of Java or C++. It doesn't have a true standard, which means that the chance of multiple entities implementing it is correspondingly lower. On the other hand, one open implementation can act as a de facto standard, so this criticism may not apply to GNUstep. Another problem for me is the syntax. Punctuation ([ : - +) is used in ways that I've never seen before. Perl is worse in this way, and I suppose that programmers who seriously use Objective-C become accustomed. Something else that bugs me is Objective-C's strong association with specific framework(s). A standard library is fine, of course, in order for a language to be useful, but I expect there to be competing libraries or toolkits for anything more complicated. I also wish that Objective-C was implemented on a common platform (Parrot, CLR, JVM), which would get rid of this issue. But then Objective-C would be competing with languages that have dynamically-typed OO as well as convenient syntax niceties that elevate the programmer above C's level. Frankly, although Objective-C is fascinating to study, I don't think it fits any important niches anymore, except possibly the niche currently occupied by C++. If you need Smalltalk-like abilities, use Smalltalk. If you just want to crunch numbers or strings at a high level of abstraction, use OCaml or Haskell. If you deeply need code that performs well, use C with a good compiler or even assembly. If you just need to solve a common problem, use a scripting language.
Here are some of the links I found:
- Love, Hate and Objective-C. This is a balanced evaluation from someone who knows much more about Objective-C than me.
- Python-Objective-C bridge. Any project that bridges languages is worth a gold star.
- Objective-C Beginner's Guide. Nice page that just shows a snippet of Objective-C example code for each signficant feature, followed by an explanation of the snippet. Every language should have a page like this, but I can see how it might be too terse for some people.
- Apple documentation for Objective-C. (pdf) All you need or want to know, from the source. I didn't read the entire thing.
- Behind the Scenes of Objective-C 2.0. What the upcoming version of Objective-C will have. I can't imagine working without garbage collection.
Saturday, November 18, 2006
the existence of mathematical entities
I've started reading The Road to Reality by Roger Penrose. I'm not far into the book at all, which stands to reason since I'm reading it slowly and in small doses. I was surprised to read that mathematical entities exist as Platonic ideals, which in effect seems to mean that their existence is neither physical nor subjective. (It reminded me of the three Worlds described by Karl Popper). In contrast, I believe that mathematics is a human creation having no independent being. That is, mathematics exists in the minds of people. It has the same claim to reality as Arda.
But you may argue, "Numbers are self-evidently real, at least because we use them to count objects and then accurately operate on those quantities". Say that I accept your argument for the time being and grant you all the whole numbers. I can do this because the whole numbers and simple 'rithmetic make up only a small sliver of modern math. Consider complex or "imaginary" numbers, which involve the square root of -1 (i), or even just negative numbers or 0. Historically speaking, these concepts did not come easily to humanity. Are these more abstract math concepts still applicable and useful, in spite of perhaps not having direct analogues to normal experience? Sure, but that's not the point. The point is to realize that from the logical standpoint of the entire math system, all numbers, whether whole or zero or negative or complex, as well as all equations and functions, have the same degree of "existence"; all belong to a system of axioms, definitions, postulates, theorems, etc. And this system was not discovered by people. It was invented, bit by bit, by starting with elementary ideas and then extending those ideas. 1 did not exist until a person wanted to represent how many noses he had.
One of the important ways in which the human creation of mathematics differs from the human creation of Rumpelstiltskin is that math proceeds logically (whereas Rumpelstiltskin isn't that logical at all). This means that mathematicians assume the truth of as few statements as they can get away with, and then show that putting those statements together leads to everything else they need. Hence the obsession of mathematicians for proofs--proofs mean that someone can rely on the truthfulness of conclusion Z13(w) provided that same someone relies on the truthfulness of some definitions and axioms. Proofs make the implicit truth explicit. The discoveries of mathematics, because the discoveries come about logically, consist of finding out what was implicitly accepted as true all along. So pi, or e, or i, are not ideal entities that eternally exist until someone finds them. That is, not like the speed of light, c. Mathematical entities, even constants, are just consequences of certain definitions. In effect, no humans created or fully comprehended the infinitely deep Mandelbrot set; they simply defined a set by defining a function that operates on complex numbers as previously defined. No human has counted every number even in the set of integers, either, but the set is infinitely large because it is defined that way.
Math does not originate or exist in the (completely objective) physical world, although the physical world displays enough order that mathematical models can correspond to it with varying degrees of accuracy. Math also does not originate or exist in a (completely objective) hypothetical world of Platonic ideals. Math is all the logical consequences of specific definitions, and the definitions in turn are/were developed by humans who used their powers of abstraction to create logical ideas out of physical reality. The same thought processes that enable generalized language (the word and representational concept of "chair" as opposed to the specific instance I'm sitting on at the moment) also enable the creation of mathematical entities. And logic, the process of combining true (abstract) statements into new true (abstract) statements, enables anyone to discover what they believed all along.
But you may argue, "Numbers are self-evidently real, at least because we use them to count objects and then accurately operate on those quantities". Say that I accept your argument for the time being and grant you all the whole numbers. I can do this because the whole numbers and simple 'rithmetic make up only a small sliver of modern math. Consider complex or "imaginary" numbers, which involve the square root of -1 (i), or even just negative numbers or 0. Historically speaking, these concepts did not come easily to humanity. Are these more abstract math concepts still applicable and useful, in spite of perhaps not having direct analogues to normal experience? Sure, but that's not the point. The point is to realize that from the logical standpoint of the entire math system, all numbers, whether whole or zero or negative or complex, as well as all equations and functions, have the same degree of "existence"; all belong to a system of axioms, definitions, postulates, theorems, etc. And this system was not discovered by people. It was invented, bit by bit, by starting with elementary ideas and then extending those ideas. 1 did not exist until a person wanted to represent how many noses he had.
One of the important ways in which the human creation of mathematics differs from the human creation of Rumpelstiltskin is that math proceeds logically (whereas Rumpelstiltskin isn't that logical at all). This means that mathematicians assume the truth of as few statements as they can get away with, and then show that putting those statements together leads to everything else they need. Hence the obsession of mathematicians for proofs--proofs mean that someone can rely on the truthfulness of conclusion Z13(w) provided that same someone relies on the truthfulness of some definitions and axioms. Proofs make the implicit truth explicit. The discoveries of mathematics, because the discoveries come about logically, consist of finding out what was implicitly accepted as true all along. So pi, or e, or i, are not ideal entities that eternally exist until someone finds them. That is, not like the speed of light, c. Mathematical entities, even constants, are just consequences of certain definitions. In effect, no humans created or fully comprehended the infinitely deep Mandelbrot set; they simply defined a set by defining a function that operates on complex numbers as previously defined. No human has counted every number even in the set of integers, either, but the set is infinitely large because it is defined that way.
Math does not originate or exist in the (completely objective) physical world, although the physical world displays enough order that mathematical models can correspond to it with varying degrees of accuracy. Math also does not originate or exist in a (completely objective) hypothetical world of Platonic ideals. Math is all the logical consequences of specific definitions, and the definitions in turn are/were developed by humans who used their powers of abstraction to create logical ideas out of physical reality. The same thought processes that enable generalized language (the word and representational concept of "chair" as opposed to the specific instance I'm sitting on at the moment) also enable the creation of mathematical entities. And logic, the process of combining true (abstract) statements into new true (abstract) statements, enables anyone to discover what they believed all along.
blog updates
I switched this blog over to the new "beta", and then I applied some labels (or tags?) to the posts and tried out the blog customization. Not too shabby. Now the WordPress blogs don't make me feel quite as inferior.
Here's some further explanation about the subject each label represents, with the caveat that this list will soon be out of date:
Here's some further explanation about the subject each label represents, with the caveat that this list will soon be out of date:
- .Net/F#. (ASP).Net or F#
- Blog Responses. A response to a post on another blog
- Metaposts. The blog
- Philosophical Observations. Sincere but amateurish remarks about (what passes here as) deep philosophical topics
- Rants. Rants that serve no constructive purpose
- Reviews. Reviews of movies, books, TV
- Software Development. Techniques, debates, and general observations of software development and programming languages
- Software Explorations. My investigations into existing software, or any original (to me) ideas for/about software
- Trivial Observations. Miscellaneous topics and comments
Thursday, November 16, 2006
the power of the sun in the palm of my hand
I use my mobile phone pretty much just for phone calls. Color me odd. But when I saw that a mobile SimCity was available, I couldn't resist giving it a whirl, if nothing else for the sake of nostalgia.
I bought SimCity Classic off the store shelf a while ago, copyright 1989, 1991. The box I still have is the same one pictured in the wikipedia article. In the lower left corner it lists the system requirements: "IBM PC/XT/AT/PS2, Compatibles", "Supports EGA, CGA, Hercules mono and Tandy Graphics", "Requires 512K (EGA 640K)", "Mouse and Printer Optional". I ran it on an XT-compatible with CGA graphics and 512K, and no mouse. It was DOS, of course, so the game had its own windowing system, along with a menu option to only animate the top window to allow better game performance. Here's a line from the manual: "Simulator reaction time is also greatly affected by your computer's clock speed and type of microprocessor. If you have an XT-compatible running at 4.77 MHz, life in SimCity will be much slower than on a 386 running at 33 MHz." Its copy protection was a red card with cities and population data. On startup, the game would ask for a statistic off the card. Any product I purchased from Maxis seemed to be reasonable on the issue of backup copies and copy protection. Considering the number of times I experienced a floppy disk failure, it was only right. Later versions of SimCity lost my interest, since the family's computer never kept current enough to play them.
Enough reminiscing. The mobile version I played had similarities to what I remembered, but actually was more complex in a few ways (to start with the obvious, a much wider range of colors). And the graphics weren't top down, but perspective-drawn, as if looking down at the city from a high oblique angle - the kind of view from a helicopter. The game was just as responsive running on my cell phone as it had on my XT-compatible, maybe more. My point is that technological advances happen so gradually that it can sometimes take a common point of reference--in this case, the game Simcity--to illustrate the great difference. My puny phone can run a game that is very similar to a game that ran on a desktop, and the phone version is even enhanced. It feels like I have the power of the sun in the palm of my hand! Almost makes you wonder if all that speculation about the Singularity isn't a huge load.
Along the same line, I ran Fractint when my family finally had a 386 (no coprocessor, which sometimes was a pain when running this program). It was an outstanding program created through the collaboration of many coders working over the Internet, or maybe it started in Compuserve for all I know; either way, Fractinct must have been the first time I'd heard of people doing that. By the time I came around to it, Fractint's feature list was incredible. In addition to many fractals and even fractal subtypes, the display parameters could be tweaked to do a slew of wild effects. It also offered a long list of video modes, any combination of resolution and colors one might want. Rather than sharing the generated images with others, the user could simply use a menu option to save the Fractint parameters that resulted in a given image and send the parameter file to another Fractint user, who could then use the corresponding menu option to load the parameters into Fractint and regenerate the image. Many of the fractals have informative documentation screens that explain the origin of the fractal and its calculation method. I could just go on and on.
As you may guess, I've kept my DOS Fractint files around just like the way I kept my SimCity materials. Any sentimental coot knows that Linux has a project, DOSEMU, that can run (Free)DOS excellently. DOSBox may be better for games, but I have had no trouble running Fractint with DOSEMU. After adding the line "$_hogthreshold = (0)" to my /etc/dosemu/dosemu.conf, which seems to be the equivalent of saying "sure, you can have my CPU, I don't need it for anything!", DOSEMU generates even the worst, most-complicated fractals of Fractint so quickly it's not even funny, in spite of the layer of indirection. Having to wait to see your fractal was such a large part of the experience...if all programs were written to perform as well as Fractint, latency in software would be a laughable concern. Here in my room is a computer that has so much more processing power than that 386, and it mostly sits idle, or whips through a web page render, or decodes a media file. It's a criminal case of waste.
I bought SimCity Classic off the store shelf a while ago, copyright 1989, 1991. The box I still have is the same one pictured in the wikipedia article. In the lower left corner it lists the system requirements: "IBM PC/XT/AT/PS2, Compatibles", "Supports EGA, CGA, Hercules mono and Tandy Graphics", "Requires 512K (EGA 640K)", "Mouse and Printer Optional". I ran it on an XT-compatible with CGA graphics and 512K, and no mouse. It was DOS, of course, so the game had its own windowing system, along with a menu option to only animate the top window to allow better game performance. Here's a line from the manual: "Simulator reaction time is also greatly affected by your computer's clock speed and type of microprocessor. If you have an XT-compatible running at 4.77 MHz, life in SimCity will be much slower than on a 386 running at 33 MHz." Its copy protection was a red card with cities and population data. On startup, the game would ask for a statistic off the card. Any product I purchased from Maxis seemed to be reasonable on the issue of backup copies and copy protection. Considering the number of times I experienced a floppy disk failure, it was only right. Later versions of SimCity lost my interest, since the family's computer never kept current enough to play them.
Enough reminiscing. The mobile version I played had similarities to what I remembered, but actually was more complex in a few ways (to start with the obvious, a much wider range of colors). And the graphics weren't top down, but perspective-drawn, as if looking down at the city from a high oblique angle - the kind of view from a helicopter. The game was just as responsive running on my cell phone as it had on my XT-compatible, maybe more. My point is that technological advances happen so gradually that it can sometimes take a common point of reference--in this case, the game Simcity--to illustrate the great difference. My puny phone can run a game that is very similar to a game that ran on a desktop, and the phone version is even enhanced. It feels like I have the power of the sun in the palm of my hand! Almost makes you wonder if all that speculation about the Singularity isn't a huge load.
Along the same line, I ran Fractint when my family finally had a 386 (no coprocessor, which sometimes was a pain when running this program). It was an outstanding program created through the collaboration of many coders working over the Internet, or maybe it started in Compuserve for all I know; either way, Fractinct must have been the first time I'd heard of people doing that. By the time I came around to it, Fractint's feature list was incredible. In addition to many fractals and even fractal subtypes, the display parameters could be tweaked to do a slew of wild effects. It also offered a long list of video modes, any combination of resolution and colors one might want. Rather than sharing the generated images with others, the user could simply use a menu option to save the Fractint parameters that resulted in a given image and send the parameter file to another Fractint user, who could then use the corresponding menu option to load the parameters into Fractint and regenerate the image. Many of the fractals have informative documentation screens that explain the origin of the fractal and its calculation method. I could just go on and on.
As you may guess, I've kept my DOS Fractint files around just like the way I kept my SimCity materials. Any sentimental coot knows that Linux has a project, DOSEMU, that can run (Free)DOS excellently. DOSBox may be better for games, but I have had no trouble running Fractint with DOSEMU. After adding the line "$_hogthreshold = (0)" to my /etc/dosemu/dosemu.conf, which seems to be the equivalent of saying "sure, you can have my CPU, I don't need it for anything!", DOSEMU generates even the worst, most-complicated fractals of Fractint so quickly it's not even funny, in spite of the layer of indirection. Having to wait to see your fractal was such a large part of the experience...if all programs were written to perform as well as Fractint, latency in software would be a laughable concern. Here in my room is a computer that has so much more processing power than that 386, and it mostly sits idle, or whips through a web page render, or decodes a media file. It's a criminal case of waste.
Tuesday, November 14, 2006
First rule of proselytization is to respect the infidel
The idea behind the clash of civilizations post was that the Java (and C#, etc.) folks have different values than the dynamic languages camp, so arguments that are completely convincing to one side are considered irrelevant by the other side. They talk over each other's heads.
However, if someone wants to try to talk across that gap, and possibly help someone cross, I think that insults are not a good start. In defense of J2EE's complexity addresses the layered, many-pieced architecture of J2EE through a historical point of view. As a general rule, technology (especially software) is invented, popularized, and evolved to serve a specific need, even if that need may be quite broad. J2EE wasn't an accident! The problem with this blog entry is the argument at the end: that software engineering should be complex enough to keep out BOZOs. chromatic called him on it over on his O'Reilly blog, because, obviously, there are many reasons for a non- or anti-BOZO to use a simpler technology.
An example of a good way to communicate with your intellectual opponents is this post by Sam Griffith. He's the same writer who previously expounded on a Java macro language, which I linked to from my MOP post a while ago. He gives Java its credit, but at the same time explains how Java could learn some things from other languages/platforms that had similar goals. Another good example is the Crossing Borders series over at IBM developerWorks (even if it exhibits the annoying trait of non-Java content in a Java-centered context). Each page in the series demonstrates an alternative approach to the common Java way of accomplishing a task, and then it compares and contrasts. Some of the articles, like one on Haskell, honestly don't seem to offer much for the Java developer, and one on web development seems to basically suggest that we should go back to embedding straight Java code in our page templates. But the one on the "secret" sauce of RoR is enlightening.
Personally, I often read these articles with a half-smirk, because the pendulum swing here is clear: we started out writing web stuff in C, then switched to Perl, then Java, and now back to Python/Ruby/PHP or what have you. The other reason for my smirk is because I'm now forced to work in ASP.Net anyway. But if Microsoft can do anything, it's copy and clone, so there's work afoot to use IronPython for more rapid web work.
However, if someone wants to try to talk across that gap, and possibly help someone cross, I think that insults are not a good start. In defense of J2EE's complexity addresses the layered, many-pieced architecture of J2EE through a historical point of view. As a general rule, technology (especially software) is invented, popularized, and evolved to serve a specific need, even if that need may be quite broad. J2EE wasn't an accident! The problem with this blog entry is the argument at the end: that software engineering should be complex enough to keep out BOZOs. chromatic called him on it over on his O'Reilly blog, because, obviously, there are many reasons for a non- or anti-BOZO to use a simpler technology.
An example of a good way to communicate with your intellectual opponents is this post by Sam Griffith. He's the same writer who previously expounded on a Java macro language, which I linked to from my MOP post a while ago. He gives Java its credit, but at the same time explains how Java could learn some things from other languages/platforms that had similar goals. Another good example is the Crossing Borders series over at IBM developerWorks (even if it exhibits the annoying trait of non-Java content in a Java-centered context). Each page in the series demonstrates an alternative approach to the common Java way of accomplishing a task, and then it compares and contrasts. Some of the articles, like one on Haskell, honestly don't seem to offer much for the Java developer, and one on web development seems to basically suggest that we should go back to embedding straight Java code in our page templates. But the one on the "secret" sauce of RoR is enlightening.
Personally, I often read these articles with a half-smirk, because the pendulum swing here is clear: we started out writing web stuff in C, then switched to Perl, then Java, and now back to Python/Ruby/PHP or what have you. The other reason for my smirk is because I'm now forced to work in ASP.Net anyway. But if Microsoft can do anything, it's copy and clone, so there's work afoot to use IronPython for more rapid web work.
Subscribe to:
Posts (Atom)