tadhg.com

Height and Negotiation

Tadhg — Tue, 16 Mar 2010 20:41:07 +0000

Taller people seem to have a number of social advantages, from increased earnings to (for men) increased desirability. It’s also an advantage in negotiations.

Various explanations for this have been posited, for example the fairly plausible idea that height correlates greater physical development earlier in life and hence to greater self-esteem.

A study cited in The Body has a Mind of its Own, however, suggests that we deal with height in a way that is both more ingrained and more shallow than that.

In summary, the Stanford study by Jeremy Bailenson sets up a virtual reality world where participants have avatars of varying heights. Participants first see their avatars in a virtual mirror and are allowed to move around and get used to their avatars (and their virtual heights). They then interact with another participant (via their avatars) and take part in a negotiation.

The outcome of the negotiations is strongly correlated to the heights of the avatars. The taller avatars do far better in the negotiation game than the shorter avatars. This appears to be the case regardless of the actual height of the participants[1].

I was quite shocked to read that[2]. Prior to reading the findings, I was pretty sure that a participant’s actual height, and their lifetime of interactions at that height, would be the determining factor and would override a few minutes of virtual play at some other height. Nope. At some level, we’re apparently wired deeply to respond to height in our interactions. So deeply that a change in height (even only virtually) will alter our responses rapidly.

This deeply ingrained heuristic is clearly rather problematic—for example, Malcolm Gladwell points out that 58% of Fortune 500 CEOs are over six feet tall, versus 14.5% of American men. While there are explanations for this that don’t rely on pervasive height bias[3], the extent of the bias and the evidence from the Bailenson study suggest that humans have a fundamental problem being rational about height. Culturally the fact that greater height leads to greater confidence, and our very wrong association of confidence with competence, means that we end up giving unfair breaks to the incompetent tall and punishing the competent-but-less-confident-or-shorter.

[1]	The Body has a Mind of its Own. Sandra Blakeslee and Matthew Blakeslee. New York: Random House, 2007. ISBN-13: 9781400064694.

[2]	So shocked, apparently, that it too me until now to recover sufficiently to write the post, having first noted it as a post idea 20 August 2008.

[3]

CEOs are generally from wealthier backgrounds, hence more likely to have had good access to nutrition going back several generations, and it’s therefore possible that some of the skew is from all the CEOs coming from a very small social class which happens to have a high percentage of tall people in it.

Tags: consciousness, economics, prejudice, psychology

Geek Conversational Behavior

Tadhg — Mon, 15 Mar 2010 21:13:53 +0000

While not a scientific study, this list of geek behaviors present during conversations strikes me as fairly useful both for “geeks” and “non-geeks”.

That being said, I favor the trend of moving the terms “geek” and “nerd” to be more generic, so that instead of referring just to gaming/computing/math, they refer to any consuming interest, e.g. “politics geek”, “knitting geek”[1], or “sports nerd”. Many of the behaviors in that article are exhibited by people who don’t fall into the traditional “geek” category—the classic example here is sports discussion, where individuals socially distant from geek stereotypes will go into great technical detail, using plenty of jargon, with a focus on completeness and accuracy.

So some of these behaviors are connected to a certain personality type[2], but others are connected to strong interest in any given complex subject (strong interest in complex subjects may itself be restricted to certain personality types, but not to the traditional geek ones).

I know I have a bunch of these, and so do friends, but certainly not all.

Since you’re probably dying to know, these are the “geek” conversational behaviors I think I exhibit with some frequency:

Obsessing over correctness and completeness. Yes, definitely. It’s a struggle for me to let factually wrong statements go by without any comment. I’m actually better at this when those statements are part of a political argument with which I disagree strongly—I can more easily file that away under “not worth it”. I also have a tough time with letting word misuse/poor spelling/etc. go by, and that’s due to a combination of altruistic desire to educate and a passionate desire to maintain the integrity of language (that subject is probably worth several posts in itself).
Preferring exact numerical responses. Yes, generally, although not usually with money, which I’ll normally round.
Using technical terms without checking for understanding. Sometimes. I think I’m actually fairly good at this. On the other hand, I think I occasionally use words that other people consider obscure without checking for understanding; that probably qualifies here.
Rapidly enumerating long lists of items. I think I do this sometimes, but not all that much.
Showing a lack of interest in outward appearances. Yes, definitely, but only in certain “modes”. I have some design geekery in me, and when the design geek switch is on I care a great deal about appearance and design. When that switch is off I care only about functionality. (In many things functionality and design are fundamentally intertwined, of course.)
Evangelizing their favorite technologies. Yes, absolutely. You should all be using open source browsers, Vim, and version control. And reStructuredText. I don’t generally push too hard on this one, but it’s there.

[1]

I suspect that one stands out; of the three examples, it’s the one I’ve never actually heard—I came up with it while thinking about activities that could clearly be “geeky”. It’s quite likely to provoke the most dissonance, and I think there’s a whole pile of gender (and status) issues hiding under that dissonance. But knitting is clearly a technical realm that people get very into, and as such is entirely capable of sustaining geekery.

[2]	I’m not sure to what extent I believe in personality types, but that’s another discussion.

Tags: culture, language, personal

Women’s Tennis Should be Best-of-Five

Tadhg — Mon, 15 Mar 2010 06:09:37 +0000

How long should tennis matches be? At the Grand Slam level, five sets. That’s the traditional answer, and all of the best matches I’ve seen have been five sets long. That’s long enough to be challenging, but not so long as to be ridiculous.

The “lesser” tournaments, e.g. not the Grand Slams or Davis Cup, are all best-of-three sets. Until recently the men’s year-end championships was best-of-five in its final match, but they changed that in 2008 (a bad move, in my opinion). A number of other tournaments also used to be best-of-three except for the final. It’s clear from this history that the longer format was and is considered appropriate for more important matches.

For Grand Slams, male tennis players switch over to best-of-five. But the female players do not, sticking with the best-of-three format. There’s really no reason for this apart from sexism.

Sexism, and the inconvenience of overturning the structures put in place by a history of sexism.

The tournaments don’t want to make such a shift because it would make scheduling much harder for them, since best-of-five matches take up more time. The female players don’t seem to be clamoring for it, which makes sense since it would be personally difficult for all of them.

It seems that basic fairness dictates that men and women should play the same format. I’m trying to think of other sports with similar gender splits. Women’s soccer doesn’t feature shorter halves—and if it did, I would be questioning that too.

There are some people who think that men’s matches should be best-of-three as well, but I think that would really be a terrible mistake, and suspect it of being driven by television advertising concerns—not by a desire to improve the sport.

Common arguments for sticking with best-of-three for women include:

Women don’t have the endurance for long matches. How could this be true? Women run marathons and compete in plenty of sports that demand endurance.
Longer women’s matches would be boring because most of them would just add an extra set of one-sidedness. Again, there’s no reason why this would be more true of women than men.
Longer women’s matches would reward the “wrong” players. Sort of the inverse of the previous argument, this is the claim that poor playes who worked on their endurance would prosper under a best-of-five system. Even if true, it’s something that would quickly change, as more female players would focus on fitness—just as the men do now.
Longer women’s matches would mean more injuries. This might be true, but again I think players would adjust. In any case, followed to its logical conclusion “injury reduction” would lead to one-set matches for both genders…
Longer women’s matches would mean more bad tennis because most women’s tennis is low quality. This is a surprisingly common argument. Its inherent sexism should be apparent—regardless of what you think of the current state of women’s tennis.
Longer women’s matches would wreak havoc with scheduling. This might be true, but so what? Lengthen the playing day, increase the number of courts, that’s just not an insurmountable problem.

All of the arguments against moving women’s Grand Slam matches to five sets are based on the idea that women are too “frail” to play that long, or that women‘s matches are somehow less worthy than men’s matches. Naked self-interest plays a part too (the tournaments don’t want to have to spend more money, and the female players currently against the idea don’t want to increase their workload.)

Making women’s matches best-of-five would promote the idea that their matches are on an equal footing as athletic endeavors with the men’s—an idea clearly in need of reinforcement. It would help puncture the idea that either gender requires “special treatment”—right now the men get more of the limelight, but on the other hand the women earn the same prize money for shorter matches, and I consider both imbalances to be unhealthy.

The signs aren’t too hopeful right now, but I’m hoping that at some point women’s tennis being best-of-three at Grand Slams becomes just one more bygone relic of a sexist past.

Tags: feminism, sports, tennis

Using Vim with Thunderbird

Tadhg — Fri, 12 Mar 2010 20:24:25 +0000

It’s possible to get Thunderbird to use Vim as an external editor for email, and while it’s a little clunky, it works.

Get the External Editor add-on for Thunderbird:
Thunderbird 2: get Version 0.7.4 from this page.

Thunderbird 3: get Version 0.8.0 from this page.
Install it via the Tools > Add-ons window.
Restart Thunderbird.
Edit the External Editor prefererences via the Tools > Add-ons window.
Enter Vim as the Text Editor (some trickiness for OS X; see below).

That should work—now, in any Compose window, you can hit Control-E (or Command-E for OS X) to invoke Vim as your editor, and it will run Vim editing your email. Saving and then quitting Vim will return you to Thunderbird with the edited message in the Compose menu.

For OS X, the right value for the path to Vim is /Applications/mvim. (mvim is a script for launching Vim that should have come with your MacVim installation.).

This can be improved further, however—if you wish, you can have a Vim instance that’s just for writing email, and you can avoid having to close it every time you’re finished editing. To do this, set the path to your Vim install as /Applications/mvim --servername email --remote-wait. Then open up Terminal and run /Applications/mvim --servername email from the commandline. You now have a Vim instance called “email”, and when you use External Editor in Thunderbird it will open the email in that instance, meaning you don’t have to move or resize the window. Also, instead of quitting Vim, you can save the file and then close it (e.g. :bd), and External Editor will place the contents of the message in your Thunderbird Compose window.

Tags: email, software, text editing, Thunderbird, Vim

This Trailer May Seem Familiar…

Tadhg — Thu, 11 Mar 2010 19:34:54 +0000

They might be aiming at an easy target, but they really nail it:

Tags: film, humor, video

Trying d-cubed for Task Management

Tadhg — Tue, 09 Mar 2010 19:58:51 +0000

I’ve been falling behind somewhat in keeping track of my tasks. That’s not to say I haven’t been productive, it’s just that most of my productivity has been focused in things I’ve been working on obsessively, like preparation for the roleplaying campaign I started running last week, Vim customization, and Python workflow coding.

It would be good to track other things better than how I’m doing it right now, but somehow returning to TiddlyWiki for my task management wasn’t appealing. I used it for quite a while, but a bare install of it doesn’t seem to quite work for task management, even though it’s still really good for keeping notes about things in general. I’m going to try d-cubed, a TiddlyWiki-based tool, instead.

One of the reasons for this is that I like a little organizational reward when I finish a task; I find that this kind of thing helps my motivation. This is partly due to my liking for lists (which may be related to my left-handedness) and partly due to the benefit of formally marking something as “done”. So a bare TiddlyWiki wasn’t quite structured enough for this, and I found that moving stuff around became too unwieldy. Instead of fixing the problem at the time, I gradually abandoned that list, and have managed mostly fine without it—but now occasionally forgetting an idea for a post is annoying me too much again.

Incidentally, this highlights my somewhat schizophrenic organizational state: various aspects of my life are either highly organized and usually stable that organized state, using some toolset that I’ve made work for me (like my blog, my subversion repository, tracking my CrossFit results, etc.); or are completely disorganized, with me getting by on them just by keeping stuff in my head and getting to it from time to time. The former is generally better than the latter, but finding the right tools for the right area isn’t always easy, especially when you’re as picky as I am (it took me a long time and quite a bit of research to settle on reStructuredText as my primary document format, for example).

In any case, I’ll see how d-cubed works; I might also try out Team Tasks, another TiddlyWiki-based tool.

During these trial periods, I’ll do my best to ignore the fact that I really want an API (preferably Pyton-based) to interact with TiddlyWikis via the command line, and that while some tools are close none match this requirement; I’ll eventually tackle that project if nobody else does, but adding another dependency in front of the task of keeping track of my tasks just doesn’t seem like a good idea, even if it wouldn’t be entirely out of character.

Tags: handedness, organization, personal, productivity, psychology, software

Inkscape

Tadhg — Mon, 08 Mar 2010 20:09:10 +0000

I’ve been using the vector graphics editor Inkscape a fair bit over the last few days, and in the last few months have given it something of a workout. It’s been quite impressive. I was never a really heavy Illustrator user, but Inkscape seems to compare to it much more favorably than, say, GIMP compares to Photoshop. It’s a later-generation product, so perhaps that’s not being fair, but regardless it just feels a lot better to use. Maybe there are killer features that Illustrator has that Inkscape doesn’t, but since I don’t know what they are, I don’t miss them…

I’ve mainly been using it for map-making (related to this), and for that it’s been really good, and I’m rather glad it exists, because doing the same kind of work in a bitmap editor would probably be incredibly frustrating. I haven’t read through the documentation, but whenever I’ve needed to find out how to do something I’ve been able to without much trouble, so it seems that they’re doing a good job on that as well.

Tags: design, games, personal, roleplaying, software

“Let’s Enhance”

Tadhg — Mon, 08 Mar 2010 00:29:16 +0000

A particularly inane trope:

In case the point isn’t crystal clear: you can’t do that. There are no image enhancement programs that let you know what the data missing at the point of capture is.

There appear to be plenty of people who think this kind of thing isn’t just possible but trivial (people who have “chosen to be smart at other things”, perhaps), at least judging by the amount of times it comes up on Clients From Hell.

I’m prepared to cut Star Trek and Blade Runner, and to a lesser extent Battlestar Galactica, some slack given that they’re science fiction, and we don’t actually know what the software capabilities or the capture format was. In Blade Runner, my interpretation of that scene is that what Deckard has his computer system analyze isn’t a simple photo, but rather some kind of hologram with a much larger amount of stored information than is apparent.

The other clips, however, deserve nothing but scorn and have no excuse. The fact that it’s doing the impossible is one thing, and then there’s also the fact that it’s a completely tired idea that exemplifies bad, lazy writing.

Put aside the first consideration for a moment and assume that this kind of technology is commonplace—you wouldn’t have characters reacting the way they do in these scenes. Either the person responsible for the analysis would simply do it themselves, or, nobody would be impressed at all by the fact that it’s possible. Instead, here you get a mixture, as if the technology exists but somehow the character is a total genius for thinking of using it.

Note that some forms of enhancement are possible; if you get a blurry shot of a license plate, it’s theoretically possible to use probabilistic analysis to get the letters or numbers, because you know in advance what the possible answers are. But that’s very different from what’s shown in those clips.

Also note: this post is not meant to imply that any other aspects of the shows referenced above are necessarily more realistic in any way.

Tags: humor, science-fiction, technology, television, video, writing

Doom and Modern First-Person Shooters

Tadhg — Sat, 06 Mar 2010 02:43:54 +0000

Continuing with the vintage video games theme, here’s “Coelacanth: Lessons from Doom”, an analysis of Doom by J.P. Lebreton, one of the designers of BioShock. Great piece, and especially interesting to me was his focus on how much easier it was for people to create their own maps for Doom than it is for modern FPSes. He wrote the commentary partly to accompany his recreation of one of his BioShock levels as a Doom II level, Arcadia Demade.

Incidentally, he’s also put work into an “abstract FPS” called purity, which makes me wonder what his take on CPMA would be.

Tags: criticism, games

Vim: the Killer Instinct of Text Editors

Tadhg — Fri, 05 Mar 2010 07:45:49 +0000

I played Killer Instinct a lot in the mid-90s. It didn’t have the multiplayer depth of Super Street Fighter II Turbo, but I wasn’t playing it multiplayer much—rather, I was trying to get the longest combination move I could.

But what does this have to do with text editing?

I’ve always been inclined to try to get things done quickly with computers. I generally try to find the keyboard shortcuts for operations and commit them to memory fast, feeling that doing otherwise will lead to a lot of wasted time, and also to there being too long a gap between my intention and its execution on the screen. This was probably most advanced (prior to now) when I was doing a lot of Photoshop work in the late 90s.

That work came after I’d been heavily into fighting games for a while. While not all fighting games do this, most of them have a concept of a “combination”, a series of moves that, if executed properly, all hit an opponent who gets hit by the first one—that is, once the combo starts, the opponent cannot block in between hits. This makes mistakes significantly more lethal, as if you leave an opening for someone who can reliably hit a powerful combo, you take a lot more damage than against someone who just knows how to hit you once or twice. Note: each “move” (sequence of inputs) can result in more than one hit; for example in Super Street Fighter II Turbo Ken’s heavy Dragon Punch (down, down/forward, forward, heavy punch) registers as three hits rather than one.

I got into playing Ken in Super Street Fighter II Turbo and focused on trying to finish opponents off with a five- or six-hit super combo (I think you could chain his super onto a heavy punch from the air), and this focus on combos made me a perfect customer for Killer Instinct, which took the combo approach and brought it to fairly ridiculous levels. Ken’s six-hit super combo in SSF2T (if you could indeed chain it onto a heavy punch) required this sequence:

Up/Forward, Heavy Punch, Forward, Down, Down/Forward, Forward, Down, Down/Forward, Heavy Punch

That’s reasonably manageable. It requires quickness and precision, because you have to do it pretty fast and the sequence has to be correct, but it’s not all that hard to remember or to execute. Killer Instinct, however, required somewhat more; here’s what Orchid’s 46-hit Ultra Combo was (if I recall correctly):

Back, Light Punch, Forward, Heavy Kick,
Back, Light Punch, Forward, Heavy Kick,
Light Punch, Back, Medium Kick,
Light Punch, Forward, Heavy Kick,
Back, Light Punch, Forward, Heavy Kick,
Forward, Medium Punch,

Down, Down/Forward, Forward, Light Punch.

I broke it onto multiple lines for clarity. That wasn’t the toughest or longest combo in the game, and there are certainly tougher ones in other games, but I think that Killer Instinct represented a clear next step from earlier fighting games in terms of combo intricacy. There’s a YouTube clip of what that input sequence results in (for reasons I won’t go into the combo in the clip results in 48 hits instead of 45, but it’s almost the same series of inputs.)

Part of the difficulty was execution and timing, but part of the difficulty was also remembering the right sequences and when they could be applied; in it and other fighting games just going for the big combo isn’t the right move every time, and you need to tailor your choice to the situation.

In that way, there’s a similarity to keyboard shortcuts in applications. This is much more significant on Windows and certain Unix systems than on OS X, because OS X doesn’t use the Alt key (plus whatever letter) to open application menus. This is one of the things I always hated about Mac OSes, and have only gotten past by figuring out other ways to get my applications to do what I want. However, where the Alt key approach is available, invoking certain actions becomes a matter of chaining together keystrokes—for example, in some versions of OpenOffice Writer, you get to the Zoom dialog by hitting Alt-V followed by Z. In applications where there are a ton of actions, remembering a sequence of Alt keypresses was often easier than memorizing the chord for each, assuming there was a chord for that particular option.

Certain other basic text handling shortcuts are similar, like (your UI’s meta key)+Left Arrow to jump back a word, or Shift+(your UI’s meta key)+Left Arrow to select all the text going back a word, but they reach a limit fairly quickly.

Your quick text manipulation capabilities rapidly reach a limit, that is, unless you’re using an editor that’s basically designed to work without a mouse, and to make text manipulation as easy as possible. Like Vim.

Vim is a modal editor, and so the typical text editor (or word processor) approach where you immediately see on the screen what you type is just one mode (Insert mode). Vim basically assumes that Insert mode is pretty easy, and that real power comes from manipulating the text in ways other than typing what you want. Where other text editors effectively give you access to non-insert modes by letting you use the mouse, or use chording keyboard shortcuts (which are often somewhat awkward), Vim gives you the whole keyboard.

h is move left, l is move right, j is move down, k is move up. So far so simple, and not better than the arrow keys. But… numbers in front of those commands make them repeat. 30k jumps up 30 lines.

What if you want to delete? d(something) deletes something. So dl would delete the next character right.

20dl deletes 20 characters right. Vim recognizes words in the sense of strings of letters broken by non-letter characters so instead of moving one cursor line or column you can move in chunks of words.

Delete the rest of the word your cursor is over? dw. Delete the next 20 words? 20dw.

The same kind of thing applies to copying and changing text; when I decided halfway through this paragraph that I wanted to remove the commas I had inserted between the keystrokes that made up the Vim combos, I hit jj to exit Insert mode, ^ to go back to the start of the line, f, to reach the first comma, x to delete it; then I realized that the rest of my line only had comma in the commands, so I hit vg$ to select to the end of the visual line, then :s/,// to replace the commas with nothing, and then A to return to Insert mode at the end of the line.

You might be looking at that wondering how the hell it’s useful to have to wade through all that crap in order to do something you could do with the mouse and a bunch of moves, clicks, and the delete key. The answer is that it’s faster this way once you know how, and that further the basic moves Vim gives you turn into combos quite naturally, and then longer ones as you learn to extend their power.

Unlike fighting game combos, in Vim you generally have as much time as you want to enter the next key for each one, but for me a lot of it is about speed. The narrower the gap between when I think of an edit and when I’ve made that edit, the better the chance of my keeping my train of thought, and more generally the more edits I can get done in a shorter time.

On top of this, I get a kick out of figuring out how to chain together the combo and execute it properly, just like I got a kick out of stringing together forty-plus hits with Orchid. It’s not exactly the same kick, but there’s enough similarity there that my brain responds positively. At the same time, it’s reinforcing the learning of skills that are extremely useful for many important tasks (such as writing and coding), and so doesn’t have the potentially unhealthy drawbacks I discussed when going over my history with Super Street Fighter II Turbo.

And I get most of those kicks without having to move my hands from the home row.

So is Vim an editor for people who like video games with ridiculously intricate move sequences? Not exclusively, no. I’m sure I’m part of a rather small minority, and Vim can be compared many other things, including Nethack, a game that’s rather far away from Killer Instinct.

If you work with text quite a lot, learning and using Vim is probably going to speed you up as much as learning to touch type (and possibly more). It’s definitely frustrating at first, but if you’re willing to put in the time to get the basics, it will prove a good investment later. I’m certainly very happy I’m using it, and (despite still having a lot of respect for jEdit) wish that I’d moved over to it earlier.

My adoption of it was slowed by my having become habituated to buffer management in other editors, and not so much by the concept of modes, or dealing with remembering what the keys did, so I don’t think my path for learning it was all that typical. Hence I don’t know if any of the tutorials I’m about to link to are any good, but hopefully you can find one that works for you.

The absolute first things you should know: i to enter Insert mode so that you can write the text you want to write; to get back to normal mode so you can edit, and move around, and start learning what the other keys do.

In Normal mode (i.e. after you’ve hit , or when you first open Vim), :help will give you help, and :vimtutor will start a tutorial.

Vim is free software and is available for more or less every platform.

Some tutorials:

Tags: games, jEdit, personal, text editing, Vim

Nethack in all its Glory

Tadhg — Wed, 03 Mar 2010 07:37:43 +0000

I’ve only played Nethack a handful of times, but have been aware of its place in the gaming pantheon for quite some time. I love the fact that a game using only symbols and text can inspire such devotion even in 2010, and reading the ascension tale of Garote-Mon-Hum-Fem-Cha makes me both curious about and wary of trying it out again.

Tags: games

A Good Work Ethic

Tadhg — Tue, 02 Mar 2010 05:00:54 +0000

I was catching up on a softer world recently, and came across this comic, which I think is one of their best.

Tags: comics, humor, web-surfing

Kate Harding Talks Sense on “Hook-up Culture”

Tadhg — Mon, 01 Mar 2010 07:55:30 +0000

Articles bewailing “these kids today” (or especially “these girls today”) seem disturbingly frequent at the moment, and it’s not clear to me whether there’s a real problem of some kind or it’s just pundits waxing wroth about the next generation Doing It All Wrong. I suspect it’s both: the sexual culture out there is problematic, although not necessarily for the reasons you hear about, and most of the pundits are really talking not to the next generation but to the next generation’s parents. This article by Rachel Simmons is an earnest but fairly typical example; this response by Kate Harding is worth reading. I don’t think Harding says anything revolutionary—she just says a lot of things that seem like common sense to me but which often get lost in the noise.

Tags: culture, feminism, gender, sex

The Future of Tabletop Games? D&D on the Microsoft Surface

Tadhg — Sat, 27 Feb 2010 02:15:35 +0000

Microsoft Surface is an advanced touchscreen display built into a table, backed by a fairly advanced suite of software for gesture recognition. I hadn’t seen many compelling uses for this technology… until SurfaceScapes, a group at the Carnegie-Mellon Entertainment Technology Center, released demos of Surfaces customized to hangle playing miniature-based D&D on them.

I strongly recommend watching the video of the demos, and reading the commentary and an interview with the project lead:

Some of it is quite clumsy, but the potential is clearly there. And looks amazing. While this could definitely aid the playing of D&D, there are many games that could benefit from this kind of treatment. Specifically, any games that benefit both from having people physically present and that would also benefit from computation and helpful interfaces (yes, I’m looking at you, Twilight Imperium) could get a huge boost from this technology.

It’s a long way away from being available or affordable, and probably a long way from being easily modifiable, too. But we don’t seem to be that far from having commonplace enhanced tabletop games. In the meantime, for roleplaying games there’s the RPTools suite—a suite which may well eventually be a big part of an open source tabletop gaming toolset.

Tags: entertainment, games, roleplaying, software, tech

A Little More Functional Programming

Tadhg — Fri, 26 Feb 2010 07:55:51 +0000

After reading Dhananjay Nene’s comment on my post about a functional style approach to the “find longest repeater” problem, I decided to follow the line from that comment and divide the program into functions for finding the longest contiguous block and then for comparing the blocks. Naturally, I wanted to do this without using any variables…

It wasn’t too hard to write a variable-free function to return a list of blocks of letters from a string, e.g. continuous_blocks("anna") produces ["a", "nn", "a"]:

def contiguous_blocks(string):
    def listbuilder(blocks, char, rest):
        if not rest:
            return add_to_blocks(char, blocks)
        return listbuilder(add_to_blocks(char, blocks), rest[0], rest[1:])

    def add_to_blocks(char, blocks):
        if blocks and char in blocks[-1]:
            return blocks[:-1] + ["".join([blocks[-1], char])]
        return blocks+[char]

    return listbuilder([], string[0], string[1:])

And then findlongestrepeater becomes:

def findlongestrepeater(string):
    def compare_blocks(previous, current):
        return current if len(current)>len(previous) else previous

    return reduce(compare_blocks, contiguous_blocks(string))

Note that this approach provides a clear use for reduce, which is on the outs in Python these days.

A crucial difference between Dhananjay Nene’s version and mine, however, is that mine returns a list and not a generator. So I decided to write a variable-free generator version… and just couldn’t do it. I don’t know what it was, but I kept getting hung up on trying to track the previous, current, and next characters, and to do that without variables while trying to skip at the right times in the for loop just seemed impossible. While writing this blog post, however, I figured it out. I had intended to put it up as a puzzle for other people, so I guess I’ll put my solution at the end. If you plan to try it, don’t scroll beyond the warning below.

There’s an easier way, too, which is simply to do this:

def contiguous_blocks(string):
    from itertools import groupby
    for k,g in groupby(string):
        yield u"".join(list(g))

I found that last night after being unable to bend my mind in the right way, because I was sure that this problem couldn’t be so rare that itertools wouldn’t have something to handle it.

However, I felt like that was cheating… so I kept trying to build my own variable-free generator.

Because of the fact that reduce isn’t going to be in Python 3, I decided I’d write a version of it that would work as its replacement for this problem. It didn’t seem too hard to come up with this:

def reducereplacement(func, generator):
    def runfunc(product, gen):
        try:
            return runfunc(func(product, gen.next()), gen)
        except StopIteration:
            return product

    return runfunc([], generator)

This only works with generators and not with lists, unlike the real reduce. There’s no reason to use this, either, given that reduce is in Python 2 and will be in the functools module for Python 3; I just wanted to try it as an experiment.

So, to restate the puzzle problem:

Write a version of contiguous_blocks that is functionally equivalent to the version above using itertools.groupby, without using the assignment operator anyhere, or anything from a module. This is a puzzle I found impossible last night but reasonably easy today. Like a lot of puzzles, looking at it in a slightly different way can make all the difference—advice which is often maddeningly useless while you’re trying to solve something.

The function, plus the version of findlongestrepeater I have above, should pass the following tests:

def test_contiguous_blocks():
    testgen = contiguous_blocks("googlee")
    assert testgen.next() == "g"
    assert testgen.next() == "oo"
    assert testgen.next() == "g"
    assert testgen.next() == "l"
    assert testgen.next() == "ee"
    assert [c for c in contiguous_blocks("google")] == ["g", "oo", "g", "l", "e"]
    assert [c for c in contiguous_blocks("googlee")] == [
        "g", "oo", "g", "l", "ee"]

def test_findlongestrepeater():
    assert findlongestrepeater("google") == "oo"
    assert findlongestrepeater("gooooogle") == "ooooo"
    assert findlongestrepeater("eeffi") == "ee"
    assert findlongestrepeater("abcdef") == "a"
    assert findlongestrepeater("eeffeeeffeeeee") == "eeeee"

WARNING, SOLUTION

Don’t read past here if you want to solve it yourself, obviously.

The key insight that helped me get it (which seems utterly obvious now, of course) is that you’re not limited to the current and next (and/or previous) characters. I’d been approaching it with logic like this:

Check the character to see if it’s different from the next character.
- If it is, return it.
- If it isn’t, pass.
But also (somehow) store it so that you know what the current sequence of repeated characters is, and when you next return something, return that sequence instead of just the current character.

I couldn’t figure out how to make that work, and it may be impossible to get Python to do that without using variables (although maybe I just missed the trick).

However, that wasn’t the right way to look at it. With access to the index of the current character, you can get not only the next character, but also string up to that point. That was the realization: the logic should be as follows:

Check the character to see if it’s different from the next character.
- If it isn’t, pass.
- If it is, return all the characters in the string up to that point that are the same as the character.

As I said, that seems awfully obvious now…

This is the solution I came up with:

def contiguous_blocks(string):
    def inarow(row, string):
        if not string or row[0] != string[0]:
            return row
        return inarow(u"".join([row, string[0]]), string[1:])

    for i,c in enumerate(string):
        if i >= (len(string) -1) or c != string[i+1]:
            yield inarow(c, string[:i][::-1])

So, if the character is different from the next one, or you’ve run out of string, yield the result of passing the character and the (reversed) string up to that point to inarow. Otherwise, if the character is the same as the next character—do nothing.

inarow doesn’t have to track anything but the characters until a different character shows up or you run out of string, so it returns what it has at that point if either of those happen, otherwise it calls itself with a new row of characters (the current one tacked onto the end) and the rest of the string.

The combination of find_longest_repeater and contiguous_blocks seems like a fairly elegant solution. Not only does it come in at two lines shorter than my version from Tuesday, but it also has the benefit of being more neatly divided in logical terms. (Which is something I wouldn’t have seen without the suggestion that the determination of contiguous blocks could be a discrete function.)

Tags: coding, python

Minor Foray into Functional Programming

Tadhg — Tue, 23 Feb 2010 23:56:05 +0000

Last night a friend asked me what functional programming was, and as part of my answer I decided to rewrite a trivial program in the functional style to see what it was like. I did this in Python without using the functional module.

The program finds the longest sequence of repeated characters in a string; if there’s a tie, it returns the first sequence of that length. My (imperative) version was six lines of Python:

def findlongestrepeater(string):
    longest, curr = "", ""
    for c in string:
        curr = "".join([curr, c]) if c in curr else c
        longest = curr if len(curr) > len(longest) else longest
    return longest

There are doubtless better ways to do it, but this is relatively succinct and clear. I can’t say the same about the functional version I came up with.

With my attempt at this example, “functional programming” basically meant “not using the assignment operator”.

I couldn’t see any way to do it without recursion, and it came out looking like a recursive decision tree:

def findlongestrepeater(string):
    def flr(lr, curseq, s):
        return lr if len(s) == 0 else character_match(lr, curseq, s)

    def character_match(lr, curseq, s):
        if s[0] == curseq[0]:
            return sequence_length(lr, u"".join([s[0],curseq]), s)
        else:
            return flr(lr, s[0], s[1:])

    def sequence_length(lr, newseq, s):
        if len(newseq) > len(lr):
            return flr(newseq, newseq, s[1:])
        else:
            return flr(lr, newseq, s[1:])

    return flr(string[0], string[0], string[1:])

flr takes arguments of the longest repeating sequence found so far, the current sequence, and the rest of the string. We kick it off by passing it the first character as the first two arguments, and then the rest of the string after the first character.

If the rest of string has a length of zero, we’ve reached the end of the string and flr returns the longest repeating sequence it was passed.

Otherwise, it calls character_match, which checks whether or not the current sequence matches the first character in the string. If not, it goes back to flr passing in the next character and the rest of the string; if so, it goes on to sequence_length passing in the longest repeater, the new sequence (which is the first character in the string plus the current sequence), and the string. sequence_length will then call flr with either the new sequence as the longest repeater, or the current longest repeater as the longest repeater.

It was pretty hard for me to approach the problem this way. It took me about forty minutes to get a working version, and another fifteen to clean it up (the first version was big jumble of conditionals). It’s also much harder to troubleshoot than the imperative version, at least for me. Recursion isn’t that hard to handle, but I really wanted to use variables just to make things clearer—for example, in character_match, I really want to replace u"".join([s[0],curseq]) with newseq = u"".join([s[0],curseq]) and then call sequence_length with newseq as the second argument, purely to make what’s going on more explicit.

It was definitely an interesting experiment, and in future I might try some exercises where I have to take functions and rewrite them without using assignment. I’m sure there are cases where this makes sense; I’m also sure that the above script would be a lot easier to deal with in a proper functional language (or perhaps using the functional module).

After doing that last night, this morning I came across an introduction to functional programming with Python.

Tags: coding, python

:imap jj and :Bclose in Vim

Tadhg — Mon, 22 Feb 2010 21:24:12 +0000

I remain rather happy with Vim, and it’s already been worth the effort of switching over to it. I’ve encountered some annoyances along the way; here are a couple of them and some solutions.

The first is that I quickly found myself wanting to exit Insert mode very frequently and not liking the stretch from my typical hand position to the Esc key. I know that some people insist that the only way to deal with this is to remap CapsLock to Esc, while others remap CapsLock to Ctrl and use Ctrl-C instead of Esc to get to Normal mode. Neither of these approaches appealed to me. Seth reminded me about another approach, one I thought would be too awkward: mapping jj to Esc within Vim.

I’d originally rejected that because it simply seemed wrong to have normal characters screw around with modes while in Insert mode—that’s what modifier keys are for! On the other hand, I don’t type “jj” too often[1] and so it seemed worth trying, especially since I wasn’t set into any of the other Vim habits yet.

It works extremely well. Being able to get out of Insert mode without moving my fingers off the home row is extremely smooth and fast, and I’ve found that after a very short period I was used to it and exiting Insert mode more fluently. Very occasionally I notice the delay when I’m typing something with a “j” in it, but that’s pretty minor, and sometimes I forget and still hit Esc, but I think that’ll go away. The only other problem I see is trying to use “jj” in other modes, like Ex mode, and expecting it to work as Esc, but I suspect that won’t be a major problem. So if you aren’t completely set in your Vim editing habits, or you’re having problems with your current setup for some reason, I highly recommend trying :imap jj out despite its seeming wrongness.

Another annoyance I encountered was that closing a buffer would also close the window it was in, and I often want to keep the window setup (usually a split) that I have. I got around this first by using the BufExplorer plugin to close files, which is definitely useful, but then I discovered that someone wrote a script to do exactly what I wanted: :Bclose. It’s worked fine so far, and if you’ve also been annoyed by that behavior I recommend trying it out.

[1]	The only even vaguely plausible reason to do so I came up with was the MTG card El-Hajjâj.

Tags: software, text editing, Vim

tadhg.com

Height and Negotiation

Related Posts

Geek Conversational Behavior

Related Posts

Women’s Tennis Should be Best-of-Five

Related Posts

Using Vim with Thunderbird

Related Posts

This Trailer May Seem Familiar…

Related Posts

Trying d-cubed for Task Management

Related Posts

Inkscape

Related Posts

“Let’s Enhance”

Related Posts

Doom and Modern First-Person Shooters

Related Posts

Vim: the Killer Instinct of Text Editors

Related Posts

Nethack in all its Glory

Related Posts

A Good Work Ethic

Related Posts

Kate Harding Talks Sense on “Hook-up Culture”

Related Posts

The Future of Tabletop Games? D&D on the Microsoft Surface

Related Posts

A Little More Functional Programming

WARNING, SOLUTION

Related Posts

Minor Foray into Functional Programming

Related Posts

:imap jj and :Bclose in Vim

Related Posts