So…the wisdom of crowds sometimes doesn’t work out. Kind of like how mob mentality doesn’t always work out.
Author Archive for Chris McAvoy
The paper I mentioned last week was published. It’s a pretty interesting read. I’ve only skimmed it, but I did find the bits I was interested in, how does the market work? They pick questions with 4-5 possible answers, like “how many gmail users will there be a) 1 million b) 2 million…” and run it for a quarter. At the end of the quarter, the securities pay out. Which backs up my belief that in order to be successful, a prediction market needs a feedback loop. It can’t just be abstract, there has to be an outcome for each security.
Ever since I started playing the Hollywood Stock Exchange, I’ve been interested in the idea of prediction markets, specifically ones that are used inside big companies to judge direction. I’ve heard that Google, Motorola, and some other biggees have them. In a guest blog post from Justin Wolfers on the Freakonomics Blog he writes that a paper will be presented at the upcoming annual meeting of the American Economic Association. From the post,
Finally, I’m really excited for a paper by Bo Cowgill, Zitzewitz, and myself that we will be debuting at this conference called “Using Prediction Markets to Track Information Flows: Evidence from Google.†I can’t say too much about the paper (yet), but I hope to describe it in a future post. Let me say that Zitzewitz and I are working with Cowgill, the Google whiz who set up an amazing set of prediction markets within Google. We use these prediction markets to track very precisely how information flows within the Googleplex and beyond. The three of us are optimistic that this may be one of the most far-reaching assessments yet of what can be learned from corporate prediction markets.
Hopefully it’ll be posted online. I don’t really understand how a prediction market can be successful without pretty direct price adjustments based on real world events. The reason HSX works (in my opinion) is because the prices are adjusted based on the actual performance of the movie. Other prediction markets, like the O’Reilly Buzz Game don’t work because there’s never adjustments based on actual performance, only adjustment based on buying and selling the shares. The price is purely based on the market, not on any performance feedback. It’ll be interesting to see how Google does it.
This is tremendously sad news. Pigeon man was a fixture on the corner across the street from Walgreens. From the article:
“Soon as I take a seat, they want to be loved and kissed like a mama’s baby,” Zeman was quoted in the Tribune article. “Like I’m their father, and they’re my child.”
Quite a well thought out rant about why Django, not Pylons. Although I agree with most of his points, I get frustrated with these posts as they end up pulling a lot of nutbags from the nutbag store, who usually act like big nutbags in the comments.
Competition and opinions are good. Comment-baiting perfectly valid projects (just because I like Django’s oomph more than Pylon’s doesn’t mean that Pylons is bad (far from it), it’s just not for me) is a fast track to not-dating-ville.
I’d like to put forward the following bit of Franklin-like common sense wisdom, “no one ever got laid by arguing about web frameworks.” Thanks Adam for putting on paper why a lot of us prefer Django to PylonTurboZopeGears, but screw you dummy blog trolls that really believe there’s some sort of conflict worth taking sides on.
Save your energy for things that matter, like football.
Clearly you and I have moved on, but I still occasionally whip you out to write one-off backup scripts, or to munge up a big text file. You and I had a really great time together. You helped me build a career, we had a lot of laughs, and a lot of sigils. Happy 20th Perl.
Amazon is starting a limited beta of an online database they’re calling SimpleDB. It’s functionally very similar to CouchDB, in that it uses REST for queries and inserts, stores data in flat “schema-less” pages, and is generally geared towards web-app-like data. The NYTimes DBSlayer takes a half-fast approach by layering a JSON REST API on top of an existing relational database.
Although these three projects each take a different stab at the same problem, they all agree on one thing, “you should really put DB in your name…somewhere.”
Amazon SimpleDB solves the problem that a lot of EC2 explorers end up running into the minute they want to have persistent data across sessions. Because EC2 is a fresh slate on each reboot, typical databases aren’t really usable, unless you spend an awful lot of time figuring out how to off-load your data to Amazon S3 on a regular basis.
I wish I had some sort of pithy analysis of the recent leanings by web-visionaries away from SQL databases and towards these sort of REST db’s. The timeline in my head goes something like this:
Raw SQL begat ORMs begat full stack web frameworks begat wrapping a REST interface around an ORM begat “hey, let’s have our controllers talk to the REST interface, rather than the ORM” begat “hey, why do we need an ORM, or a traditional database? Let’s just make a REST accessible database!”
I guess that’s relatively pithy.
Really though, I’m not entirely sure what to make of this “trend.” I’ve yet to build even a trivial project using any of the three (Amazon is a closed beta, so I’m not sure if it’ll even be a possibility anytime soon). Maybe it’s time I take a crack at one of them.
I’ve blogged about my random obsession with bees in the past. The release of Pyglet encouraged me to pick it up again and try to make a bee-system associated with coordinates rather than with abstract “locations.”
Over the weekend, I started to write a trig library that could compute angles and distances, so I could move my bees around a grid. It turns out, I’m pretty bad at math. Brant Harris sat down and explained Vectors to me in about 15 minutes. I immediately ditched my trig library, and built a basic Vector bee demo in a half hour or so last night. The code for it is in my expansive public-works repository. In that same module is trig.py, which is the start of the trig library I ended up ditching. The Vector work was already written in PyEuclid, the very excellent Euclidian Geometry library written especially for Pygame development.
The code, suitable for cutting and pasting, is as follows:
[source:python]
#!/usr/bin/env python
# notes on how to use vectors to move the bees around in pyglet
from euclid import Vector2 as v
from pyglet import window
from pyglet import font
from random import randint
b = v(1,1) # bee at 1,1
h = v(150,150) # hive at 4,4
def in_range(b, h):
# return true if magnitude (distance) is less than 1
return (b - h).magnitude() < 1
# move the bee one tick towards the hive
def move_towards_hive(b,h):
return b + ( h - b ).normalized()
def move_random(b):
return b + (v(randint(0,100), randint(0,100)) - b).normalized() * 5
win = window.Window()
ft = font.load(’Arial’, 18)
while not win.has_exit:
win.dispatch_events()
while not in_range(b,h):
b = move_random(b)
print “b: %s h: %s” % (b, h)
win.clear()
b_text = font.Text(ft, ‘b’, x=b.x, y=b.y).draw()
h_text = font.Text(ft, ‘h’, x=h.x, y=h.y).draw()
win.flip()
[/source]
http://us.pycon.org/2008/conference/proposals/
Just a heads up.
I think this will be the first year I actually propose a talk.

Recent Comments