No one on this thread has mentioned a “prisoner’s paradox”. We have been discussing the Prisoner’s Dilemma, a well known and standard problem in game theory which involves two players who must decide without prior knowledge of the other player’s decision.
Prisoner’s paradox is another term for the prisoner’s dilemma. See for example this Wikipedia redirect. You may want to reread what I wrote in that light. (Although there’s some weird bit of illusion of transparency going on here in that part of me has a lot of trouble understanding how someone wouldn’t be able to tell from context that they were the same thing.)
A different problem in which neither player is actually making a decision, but instead is controlled by a deterministic algorithm, and in which both players, by looking at source, are able to know the other’s decision in advance, is certainly an interesting puzzle to consider, but it has next to nothing in common with the Prisoner’s Dilemma besides a payoff matrix.
No. The problem of what to do is actually closely related when one has systems which are able to understand each others source code. It is in fact related to the problem of iterating the problem.
In general, given no information, the problem still has relevant decision theoretic considerations.
The problem of what to do is actually closely related when one has systems which are able to understand each others source code. It is in fact related to the problem of iterating the problem.
I’m curious why you assert this. Game theorists have a half dozen or so standard simple one-shot two person games which they use to illustrate principles. PD is one, matching pennies is another, Battle of the Sexes, Chicken, … the list is not that long.
They also have a handful of standard ways of taking a simple one-shot game and turning it into something else—iteration is one possibility, but you can also add signaling, bargaining with commitment, bargaining without commitment but with a correlated shared signal, evolution of strategies to an ESS, etc. I suppose that sharing source code can be considered yet another of these basic game transformations.
Now we have the assertion that for one (PD is the only one?) of these games, one (iteration is the only one?) of these transformations is closely related to this new code-sharing transformation. Why is this assertion made? Is there some kind of mathematical structure to this claimed relationship? Some kind of proof? Surely there is more evidence for this claimed relationship than just pointing out that both transformations yield the same prescription—“cooperate”—when there are only two possible prescriptions to choose among.
Is the code-sharing version of Chicken also closely related to the iterated version? How about Battle of the Sexes?
So I’m going to need to repeat my earlier disclaimer that I’m far from my area of expertise. But the basic idea is that iterating games gives you a probabilistic estimate for what the underlying code looks like (assuming some sort of nice distribution on potential source code such that in general simpler code is more likely than complicated code). Unfortunately, I don’t know any details of this approach beyond its existence but it should apply to other games like Chicken also.
Prisoner’s paradox is another term for the prisoner’s dilemma. See for example this Wikipedia redirect. You may want to reread what I wrote in that light. (Although there’s some weird bit of illusion of transparency going on here in that part of me has a lot of trouble understanding how someone wouldn’t be able to tell from context that they were the same thing.)
No. The problem of what to do is actually closely related when one has systems which are able to understand each others source code. It is in fact related to the problem of iterating the problem.
In general, given no information, the problem still has relevant decision theoretic considerations.
I’m curious why you assert this. Game theorists have a half dozen or so standard simple one-shot two person games which they use to illustrate principles. PD is one, matching pennies is another, Battle of the Sexes, Chicken, … the list is not that long.
They also have a handful of standard ways of taking a simple one-shot game and turning it into something else—iteration is one possibility, but you can also add signaling, bargaining with commitment, bargaining without commitment but with a correlated shared signal, evolution of strategies to an ESS, etc. I suppose that sharing source code can be considered yet another of these basic game transformations.
Now we have the assertion that for one (PD is the only one?) of these games, one (iteration is the only one?) of these transformations is closely related to this new code-sharing transformation. Why is this assertion made? Is there some kind of mathematical structure to this claimed relationship? Some kind of proof? Surely there is more evidence for this claimed relationship than just pointing out that both transformations yield the same prescription—“cooperate”—when there are only two possible prescriptions to choose among.
Is the code-sharing version of Chicken also closely related to the iterated version? How about Battle of the Sexes?
So I’m going to need to repeat my earlier disclaimer that I’m far from my area of expertise. But the basic idea is that iterating games gives you a probabilistic estimate for what the underlying code looks like (assuming some sort of nice distribution on potential source code such that in general simpler code is more likely than complicated code). Unfortunately, I don’t know any details of this approach beyond its existence but it should apply to other games like Chicken also.