Archive for August, 2009

Pokerbot Lesson: Work Hard During the Good Times

August 26, 2009 at 9:03 pm · Filed under Random Thoughts ·Tagged , , ,

As I mentioned in an earlier post, I wrote a poker bot in 2004.  I learned a lot from that project, and I’d like to share some of the lessons learned over a series of blog posts.

All poker players are familiar with the game’s swings.  Poker’s unpredictable sequence of wins and losses stems from the addictive cocktail of uncertainty and randomness that makes the game so popular.  There are many lessons to learn while riding the roller coaster of wins and losses, but I’ll focus on one that’s particular to a poker bot author (or an investor in the markets).

Imagine if you unleashed your poker bot algorithm and observed the following performance over the first 10,000 hands.

Pokerbot performance over 10,000 hands

Pokerbot performance over 10,000 hands

It takes a poker bot about 22 hours to play 10,000 hands.  This assumes that the bot plays 10 tables simultaneously, averaging 45 hands per hour at each table.  For comparison, it takes a human about 28 days to play 10,000 hands, assuming he plays an intense 30 hands an hour, 12 hours a day.  Although it’s not a large enough sample to yield a statistically significant win rate, it’s a sizable sample.

The first couple of times that this happened to me, I couldn’t help myself from leaning back and thinking that my troubles were over.  Instead of analyzing more data or writing more code, I’d relax.  Then I’d see this turn of fortune.

Fictional graph of big bets won or loss over time.

Fictional graph of big bets won or loss over time.

The downturn would give me a kick in the pants, and I’d dive in again to my work with vigor.

After this pattern happened a couple times, I realized how much time I was wasting.  Frustrated by this inefficient cycle, I made a point of staying vigilant even when the results looked promising.  I learned that you have to work hard even when everything’s going smoothly.

This lesson is applicable to both investing and software development.  When your PnL is positive, you need to make an extra effort to stay sharp.  When you’re writing software, you can’t assume that your program is correct just because it runs without throwing off errors.  Be suspicious and stay vigilant, even when things seem okay.

Comments (2)

My Pokerbot’s Architecture

August 20, 2009 at 8:27 pm · Filed under software ·Tagged ,

Back in 2004, I spent most of my time building a poker bot to play low stakes limit texas holdem.  (A poker bot is a program that automatically plays poker against humans on one of the major internet poker sites).  The project consumed me.  It was both challenging and exciting.  I successfully ran the bot for a few years before shutting it down when I took my first job on Wall Street.

I worked alone on the poker bot.  I designed and implemented the poker client interface, the AI, and monitoring framework.  Since then, I’ve enjoyed reading a few blog posts detailing the efforts and celebrations of other poker bot creators.  Just today I read this one.  I’d like to join the party and share some details about how I built my bot.

PokerBotArchitecture

When I started the project, I wasn’t sure how to interface with the poker client.  The poker sites don’t provide an API, so I either had to reverse engineer the network protocol or build a screen scraper.  I knew a lot about hacking network protocols, and I had never built a screen scraper.  (I also noticed that one of the sites used an open source SSL library that I could swap out).

Despite these advantages, I wanted to build a screen scraper because:

  1. It’s harder for the poker client to detect a screen scraper.  I didn’t want exhibit an identifying communication fingerprint.
  2. I didn’t want to reverse engineer multiple network protocols.  It seemed easier to get a screen scraper working on different poker clients.

I wrote the scraper using C#.  One weakness of my scraper was that the windows all had to be a certain size, and they could not overlap.  I worked around this by building a simple tiling window manager with an AutoHotKey script.

I routed information from the scraper through a piece of software that I called the poker gateway.  This gateway directed information to a hand history database, poker AI, lobby AI, and control center.  All of these components ran on a separate linux box, and I used Ruby to develop them all.

This architecture was robust and flexible.  As a result, I could focus most of my energy and thought on building the AI.

I’d enjoy hearing from other poker bot creators.  It would be fun to swap war stories.

Leave a Comment

Acknowledgements to Bernie Madoff

August 19, 2009 at 11:01 am · Filed under Random Thoughts ·Tagged ,

Last night I started reading Trading and Exchanges: Market Microstructure for Practitioners, by Larry Harris.  I was surprised to see Bernie Madoff mentioned in the book’s acknowledgments.  Dr. Harris thanks both Bernie and Peter for “their early support” that allowed him to “take time off from my teaching to start this project.”

Curious, I searched Google Books for books published before 2007 that mention the great ponz.  The search yields a number of results — pretty amusing.

Leave a Comment

Navigating New York’s Attitude toward Technologists

August 17, 2009 at 5:52 pm · Filed under Business, Random Thoughts ·Tagged , , , , ,

I just read Zed Shaw’s post where he announces that he found a job in San Francisco.  Congratulations to him.  In his post, I appreciated his concluding comparison of how companies in New York and San Fran perceive and approach technologists.  Zed says:

NYC prospects were looking for a badass/ninja/rockstar beta-male “techie” employee to make them rich creating lame applications for giant Finance/Fashion/Marketing companies.  SF prospects were looking for a partner to get rich with them creating great products for customers.

To a large extent, I agree.  New York is filled with companies that have non-technical core competencies.  These businesses treat technology as a necessary cost.  When they search for a rockstar ninja, their goal is to minimize cost.  The thinking is “that last tech we had was too slow and too sloppy, and his mistakes cost us money.  We need a superstar tech guy to come in here and do things right (not screw up).”

The dynamic is top-down.  The business wants a super star who will take orders and work efficiently.  On the whole, this makes perfect sense.  As Judge Smails says, “the world needs ditch diggers, too.”

This system fails for superstar techies like Zed Shaw.  This class of techies are often prima donna’s in the same vein as star wide receivers in the NFL.  Instead of taking orders, they want to provide advice.  Instead minimizing cost, they want to generate value.  Indeed, they want to be partners, not employees.  (Even if the company pays well, as many New York firms do).

San Francisco, on the other hand, is a town filled with ninjas looking to band together.  Each one is a Steve Jobs looking for a Steve Wozniak to join them in the garage.  This is a natural and attractive situation, as evidenced by Zed’s move from his beloved LES.

New Yorkers do have hope.  The key is to pursue and promote every opportunity to increase revenue instead of decreasing costs.  When you see this opportunities, you need to explicitly point them out.  Then, if you’re given the green light, work extra hard to execute.  If you score a couple wins, then you can take a partnership role (even in New York).

Comments (1)

Book Review: Nerds on Wall Street by David Leinweber

August 11, 2009 at 10:50 pm · Filed under Book Review ·Tagged , , , ,

This weekend I read David Leinweber’s book Nerds on Wall Street: Math, Machines and Wired Markets.  While sitting at Radiance Tea, I read a book review in the Wall Street Journal.  Since I had previously enjoyed David’s chapter in How I Became a Quant, I paid $24 and instantly downloaded it to my Kindle.

David’s has a clear, concise, and humorous writing style.  Also, since I’m also a (significantly more junior) nerd on Wall Street, I’m in his target audience.

My big takeaway is the sense of pragmaticism and passion that oozes out of his stories. It’s clear that technology makes him tick, and that he’s always right on top of the newest techniques.  And he’s been at it for years, so his stories all carry true gravitas.

Data mining while developing quantitative strategies is one principal theme that’s addressed in most of the book’s chapters.  Personally, I wish he had addressed this in greater detail.  It’s easy to dismiss eggregious data mining that links butter production to S&P returns.  It’s also easy to say “withhold data from your training data.” I also felt that when he discussed a specific example of using genetic programming, he essentially admitted that the strategy was datamined, yet restrained by common sense.

I recommend this book.  It’s a quick and enjoyable read about an interesting topic.

Leave a Comment

I don’t use debuggers

August 11, 2009 at 8:13 pm · Filed under Programming Languages, Random Thoughts ·Tagged , ,

I just read this post, which says “Just about every developer uses a debugger, at least occasionally.”  I don’t know if I’m inadequate or working on a peculiar class of problems, but I haven’t used a debugger in roughly 10 years.

I have used a debugger twice.  Once I was chasing down a bug in a boutique embedded systems compiler.  The compiler had a bug, and staring at the C code didn’t cut it.  I also used the Perl debugger while writing my MS thesis (back when I wrote oodles of Perl code).  I used it because a friend showed it to me, and it seemed cool.

My primary debugging technique is code examination.  I simply look carefully at my code and think about it.  I also write unit tests.

I’m not fundementally opposed to debuggers.  It’s just that I haven’t used one in the past 10 years.

Leave a Comment

Follow

Get every new post delivered to your Inbox.