Given Rice's theorem, there is no source code analysis that is guaranteed to tell you anything interesting about your opponent, unless your opponent has been written in such a way as to facilitate that analysis. This suggests two possible modifications of the competition.

Firstly, the rule could be imposed that source code is unanalysable. A competing program will not be furnished with its opponent's source, but only an opaque blob. The only operation they can perform on this blob is to supply it with another blob and see what answer it gives. Each program is given access to itself (as an opaque blob), and can contain within itself whatever other blobs it wishes to use for probing purposes. Note that if every program begins a contest by running its opponent on some example, then no-one terminates and everyone loses. Therefore a program must sometimes make a decision without having run its opponent on any examples. This looks like it severely limits the usefulness of simulating the opponent to see what it will do, perhaps to the point where it is impossible to gain anything from it, and the competition reduces to an ordinary PD tournament.

Alternatively, source code would be revealed, but in addition each program would be allowed to furnish machine-checkable proofs of assertions about itself. The machine checking would be part of the infrastructure of the competition, so competitors would be able to have complete trust in these assertions.

Or one could combine these: one receives one's opponent as an unanalysable blob together with some set of guaranteed true assertions about it, supplied by the creator of that program and verified by the competition infrastructure. The idea is that skill at analysing someone's source code is secondary to the point of the exercise.

What verifiably true assertions would it be useful for a competitor to make about itself? It would be easy to write code of which it can be proved "I always cooperate", "I always defect", "I play Tit For Tat", or any of the other ordinary PD strategies. What verifiable assertions can a program make about the sort of opponent it will cooperate or defect with? "I will cooperate with anyone who cooperates with me" would not be an admissible assertion (by Rice's theorem). Nor would "I will cooperate with anyone who verifiably asserts that they cooperate with me". But "I will cooperate with anyone who verifiably asserts that they cooperate with anyone verifiably asserting this sentence" might be, if the circularity can be handled.

ETA: But "I will cooperate with anyone who verifiably asserts that they cooperate with anyone verifiably asserting a sentence logically equivalent to this one" won't work. So there would have to be a negotiation phase before the competition in which people publish the assertions they want to make about themselves, so that people can coordinate to agree on the exact formualtion of the mutually referential sentences they want to be seen to be true of them.

It's posts you haven't read before. I think writing a post doesn't count as reading it. Also, the newest open thread is this one.

Why do some posts have pink borders?

I can't quite figure it out. I gather it has something to do with being new, since newer posts are more likely to be pink and every reply to a pink post seems to be pink. But it's not purely chronological (since some of the most recent comments do not have pink borders when I view the thread), and it's not purely based on being new since the last time you've viewed a thread (since I've seen pink borders around my own posts).

+1 for restricted Scheme. I suggest restricted Python because it is more accessible and would allow more people to participate, but personally I like Scheme a bit more.

On the other hand, many many people were turned off by Scheme last time, and few of them will be reading this post. I'd like to give them a shot, if only to get a more diverse crowd.

On looping constructs: Would that buy us anything? What if people use recursion for looping? Should we restrict recursion?

Question for the audience: would there be a benefit to using a programming language that allows only primitive recursive functions?

Yay, I wasn't last!

Still, I'm not surprised that laziness did not pay off. I wrote a simple bot, then noticed that it cooperated against defectbot and defected against itself. I thought to myself, "This is not a good sign." Then I didn't bother changing it.

The most important difference between Level 1 and Level 2 actions is that Level 1 actions tend to be additive, while Level 2 actions tend to be multiplicative. If you do ten hours of work at McDonald's, you'll get paid ten times as much as if you did one hour; the benefits of the hours add together. However, if you take ten typing classes, each one of which improves your ability by 20%, you'll be 1.2^10 = 6.2 times better at the end than at the beginning: the benefits of the classes multiply (assuming independence).

Nitpick: You cheated by stipulating that each typing class has a multiplicative effect. This is just saying that additive things tend to be additive, while multiplicative things tend to be multiplicative.

I agree with your larger point... but the multiplicative effect comes in because the typing gains apply to every typing task you perform over the rest of your life.

After the top 5 or 10 or so, rather than just presenting a list of articles, it may make more sense to split things up by topic. Being presented with a list of 100 articles is kind of intimidating. Being presented with five lists of twenty articles each on five different topics is less so, as it's easier to divide and conquer. Readers may be interested in some topics but not others (at least at first), or may decide to read a few articles on each topic.

Some natural subdivisions might be:

• Human psychology and biases.
• Bayesian inference.
• The scientific method.
• Quantum mechanics.

Also, others have mentioned sequences. Rather than just ignoring that sequences exist, it would be useful to new readers both to point out the sequences (which would happen more naturally if you broke things up by subject), and to provide the reader with some idea of how important it is to read a given sequence in order.

No person may contribute to more than one entry.

This is important, because otherwise the contest devolves into who can submit the most copies of AbsolutismBot (cooperate with programs that share it's source code, otherwise defect)

I think that any submitted program can be improved by combining it with AbsolutismBot. If you're playing with someone who submitted the same program for you, cooperate (they can't defect against you in this scenario, since they're running identical source code). If they aren't running the same code, run whatever program lies underneath it.

I think this could get generalized to cooperation with everyone who has the AbsolutismBot "wrapper", since it doesn't matter what the code after the AbsolutismBot section does. In English (since I don't know how to program in Scheme), the program would be like this:

If the first 117 characters of the other program are the same as the first 117 characters of this program, cooperate. Otherwise, do some other strategy.

All players that implement this strategy will cooperate with each other. Granted, this doesn't help them win the tournament since it isn't a relative advantage compared to other AbsolutismBots - it just makes everyone who doesn't do this lose the tournament.

1. Get a bunch of capital.

2. Go to a poor country (specifically, a country where food and buildings are cheap).

3. Build a great big school.

4. Offer the following deal to parents of gifted children: they send their children to you, and you'll educate them for free, for ten years. At the end of ten years, the newly educated young adults either go to college, get a job, or be a bum. If at any point they do start working, you get (say) 10% of their income for 10 years.

5. Do it smartly: Skimp on "humanities"; no ancient literature for these kids. Reading, writing, math, science, programming. Get them ready for future jobs by giving them deep, versatile, malleable skills.

6. Do it cheaply: Use technology as efficiently as possible, so you don't have to pay for too many instructors. A campus wide internet connection and a $100 netbook per kid should get most of the possible value; maybe have some real computers for the programmers. Obviously you still need some instructors.

7. Do it morally (this might rule it out completely, since you are kind of creating indentured servants, and also because you are sucking cognitive resources from that area).

8. Profit!

This is feasible because the biggest resource is still human cognitive resources. I'd bet that poor countries have untapped smart brains.

I have discovered a way to carry a credit card balance indefinitely, interest-free, without making payments, using only an Amazon Kindle.

How my card works is, any purchases made during Month N get applied to the balance due in the middle of Month N+1. So if I make a purchase now, in May 2013, it goes on the balance due June 15th. If I don't pay the full May balance by June 15th, then and only then do they start charging interest. This is pretty typical of credit cards, I think.

Now the key loophole is that refunds are counted as payments, and are applied immediately, but purchases are applied to the balance due next month. So if I buy something on June 5th, and return it on June 6th, the purchase goes toward the balance due on July 15th, but the refund is applied as a payment on the balance due on June 15th! So you can pay your entire June balance with nothing but refunds, and you won't have to worry about paying for those purchases until July, at which time you can do the whole thing again. The debt is still there, of course, because all you've done is add and then subtract say $100 from your balance, but absolutely no interest is charged. This process is limited only by your credit line (which you cannot exceed at any time) and by the ease with which you can buy and return stuff each month.

Here's where the Kindle comes in. Repeatedly buying and returning items from a brick-and-mortar store is incredibly time-consuming and risky. You have to buy stuff, keep it in good shape, and then return it, interacting with human clerks each time, without raising suspicion. Not efficient. But if you have a Kindle, you know that when you buy a book, after you hit "Purchase" a screen comes up that asks if you have bought the item by accident, and if so, would you like to cancel the purchase. If you hit the button to cancel the purchase, what happens is that the purchase is still applied to your card, but it is refunded a couple of days later. Bingo. Automatic refunds, obtained at home at no risk, with no human oversight.

But e-books on Amazon are like $10, so you'd have to sit there all day hitting "buy" and "return" to shift a significant amount of debt, right? Wrong. If you know where to look, the Amazon kindle store has lots of handbooks, technical manuals, and textbooks that cost hundreds of dollars. Start out searching for "neurology handbook" and just surf the "similar books" list from there. Buy and return a few of those, and you're set for another month.

Obviously you have to pay off the debt at some point. This is not free money. But if you're in a tight spot for a few months, it's incredibly useful. And hey, if the inflation-adjusted prime rate is 0%, why should you have to pay interest? You're good for it.

This is by far the most munchkin-like idea I've ever had, and I'm pretty happy about it. I've been using it since January, making real payments toward my card as I can, and covering the rest with Amazon buy-and-returns. I know I'll pay down the debt when I have a better job, but in the meantime it is really nice not to have to pay any interest on it.