|
|
Re: (difficult)Theoretical gambling puzzle (solution?)
Posted:
Jul 26, 2006 8:18 AM
|
|
I finally extracted humain readable instructions corresponding to my strategy:
- With 26 negative (black) cards in hand, stop after your gain reaches 0
- 24 to 25 ... 1
- 21 to 23 ... 2
- 16 to 20 ... 3
- 10 to 15 ... 4
- 3 to 9 ... 5
- 0 to 2 ... 6
The expected gain is 2.624475...
-- Eric
At 13:42 26/07/2006, Joao Pedro Afonso wrote:
> Mines are the same until 5+5. Then yours
> starts to be better. I have still to see where
> is the flaw in my process, but the data you
> sent is a good starting point. What I do is to
> define the probability of gaining at least one
> more point against the possibility of loosing
> all accumulated. If the expected loss in the
> second case is greater than the probability of the first,...
>
> oh oh!...
>
> I'm seeing the problem now. Strange that I
> thought my strategy would be equivalent to
> yours. I thought I was doing something
> incremental, judging the gains of trying for
> one more, case by case. Each time, I judge the
> reward of searching for one more against the
> possibility of loosing all. The flaw is, since
> the process is dynamic and don't stop in the
> next success, The searching for the next point
> can be also the search for the point after (and
> so one), and so, the expected reward is
> slightly higher than the one I calculated, and
> in some cases, greater than the potential
> losses. My rule stops earlier than it should be.
>
>The big mystery now, is to understand why my rule, even so, functions so well.
>
>[Why I didn't found it earlier? I was convicted
>my process was doing what yours are doing. I
>didn't found any flaw in your program because it
>was according to what I was expecting from the
>optimal algorithm, even a little cleaner than
>mine... I never thought to question my method,
>because I was convicted it was up to the idea, and pass that test].
>
>
> Cheers,
>Joao Pedro Afonso
>
>
>Eric Bainville wrote:
>>Hi,
>>Here are the initial values given by my method:
>>2+2 => 2/3
>>3+3 => 17/20
>>4+4 => 1
>>5+5 => 47/42
>>6+6 => 284/231
>>7+7 => 4583/3432
>>8+8 => 18457/12870
>>9+9 => 74131/48620
>>10+10 => 26995/16796
>>-- Eric
>>At 08:13 26/07/2006, João Pedro Afonso wrote:
>>>Hi Eric,
>>>
>>> My method is very similar to yours (but not
>>> exactly equal) and I don't understand why it
>>> doesn't give the same values, yet. But I
>>> didn't found any problems in the reasoning,
>>> so, maybe the small diferences are
>>> significative and you have a better stop
>>> criteria. Can you send the expected values
>>> for 2+2, 3+3, and 4+4. To 2+2, it is easy to see it must be 2/3.
>>>
>>>
>>> Cheers,
>>>Joao Pedro Afonso
|
|
