[R] Two envelopes problem

Duncan Murdoch murdoch at stats.uwo.ca
Tue Aug 26 20:06:50 CEST 2008


On 8/26/2008 1:12 PM, markleeds at verizon.net wrote:
>   Duncan: Just one more thing which Heinz alerted me to. Suppose that we 
> changed the game so that instead of being double or half of X,
> we said that one envelope will contain X + 5 and the other contains X-5. 
> So someone opens it and sees 10 dollars. Now, their remaining choices
> are 5 and 15 so the expectation of switching is the same = 10.  So, in 
> this case, we don't know the distribution of X and yet the game is fair. 

No, you can't do that calculation without knowing the distribution. 
Take my first example again:  if X is known in advance to be 1,2,3,4, or 
5, then an observation of 10 must be X+5, so you'd expect 0 in the other 
envelope.  The conditional expectation depends on the full distribution, 
and if you aren't willing to state that, you can't do the calculation 
properly.

Duncan Murdoch



> This is
> why , although I like your example, I still think the issue has 
> something to do with percentages versus additions.
> 
> In finance, the cumulative return is ( in non continuous time )  over 
> some horizon  is a productive of the individual returns over whatever 
> intervals
> you want to break the horizon into. In order to make things nicer 
> statistically ( and for other reasons too like making the assumption of 
> normaility somkewhat more plausible ) , finance people take the log of 
> this product in order to to transform the cumulative return  into an 
> additive measure.
> So, I think there's still something going on with units as far as adding 
> versus multiplying ? but I'm not sure what and I do still see what 
> you're saying in
> your example. Thanks.
> 
>  
> Mark
> 
> 
> 
> On Tue, Aug 26, 2008 at 11:44 AM, Mark Leeds wrote:
> 
>> Hi Duncan: I think I get you. Once one takes expectations, there is an
>> underlying assumption about the distribution of X and , in this 
>> problem, we
>> don't have one so taking expectations has no meaning.
>>
>> If the log utility "fixing" the problem is purely just a coincidence, 
>> then
>> it's surely an odd one because log(utility) is often used in economics 
>> for
>> expressing how investors view the notion of accumulating capital 
>> versus the
>> risk of losing it. I'm not a economist but it's common for them  to
>> use log utility to prove theorems about optimal consumption etc.
>> Thanks because I think I see it now by your example below.
>>
>>                                            Mark
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Duncan Murdoch [mailto:murdoch at stats.uwo.ca] Sent: Tuesday, 
>> August 26, 2008 11:26 AM
>> To: Mark Leeds
>> Cc: r-help at r-project.org
>> Subject: Re: [R] Two envelopes problem
>>
>> On 8/26/2008 9:51 AM, Mark Leeds wrote:
>>> Duncan: I think I see what you're saying but the strange thing is 
>>> that if
>>> you use the utility function log(x) rather than x, then the expected
>> values
>>> are equal.
>>
>>
>> I think that's more or less a coincidence.  If I tell you that the two 
>> envelopes contain X and 2X, and I also tell you that X is 1,2,3,4, or 
>> 5, and you open one and observe 10, then you know that X=5 is the 
>> content of the other envelope.  The expected utility of switching is 
>> negative using any increasing utility function.
>>
>> On the other hand, if we know X is one of 6,7,8,9,10, and you observe 
>> a 10, then you know that you got X, so the other envelope contains 2X 
>> = 20, and the expected utility is positive.
>>
>> As Heinz says, the problem does not give enough information to come to 
>> a decision.  The decision *must* depend on the assumed distribution of 
>> X, and the problem statement gives no basis for choosing one.  There 
>> are probably some subjective Bayesians who would assume a particular 
>> default prior in a situation like that, but I wouldn't.
>>
>> Duncan Murdoch
>>
>> Somehow, if you are correct and I think you are, then taking the
>>> log , "fixes" the distribution of x which is kind of odd to me. I'm 
>>> sorry
>> to
>>> belabor this non R related discussion and I won't say anything more 
>>> about
>> it
>>> but I worked/talked  on this with someone for about a month a few 
>>> years
>> ago
>>> and we gave up so it's interesting for me to see this again.
>>>
>>>                                            Mark
>>>
>>> -----Original Message-----
>>> From: r-help-bounces at r-project.org 
>>> [mailto:r-help-bounces at r-project.org]
>> On
>>> Behalf Of Duncan Murdoch
>>> Sent: Tuesday, August 26, 2008 8:15 AM
>>> To: Jim Lemon
>>> Cc: r-help at r-project.org; Mario
>>> Subject: Re: [R] Two envelopes problem
>>>
>>> On 26/08/2008 7:54 AM, Jim Lemon wrote:
>>>> Hi again,
>>>> Oops, I meant the expected value of the swap is:
>>>>
>>>> 5*0.5 + 20*0.5 = 12.5
>>>>
>>>> Too late, must get to bed.
>>>
>>> But that is still wrong.  You want a conditional expectation, 
>>> conditional on the observed value (10 in this case).  The answer 
>>> depends on the distribution of the amount X, where the envelopes 
>>> contain X and 2X.  For example, if you knew that X was at most 5, you 
>>> would know you had just observed 2X, and switching would be  a bad 
>>> idea.
>>>
>>> The paradox arises because people want to put a nonsensical Unif(0, 
>>> infinity) distribution on X.  The Wikipedia article points out that 
>>> it can also arise in cases where the distribution on X has infinite 
>>> mean: a mathematically valid but still nonsensical possibility.
>>>
>>> Duncan Murdoch
>>>
>>> ______________________________________________
>>> R-help at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-help
>>> PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html
>>> and provide commented, minimal, self-contained, reproducible code.
>>
>> ______________________________________________
>> R-help at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide 
>> http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.



More information about the R-help mailing list