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...
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