dionisos wrote:My point is that by knowing that you've predefined the win of this game is defined as either a '3' on the dice or a '2 and heads' on a dice/coin combination. But because I know this ahead of time, I know that all that counts for this given RESULT is 2/7 because I know if I toss a dice roll of a '4', I don't have to bother tossing the coin already knowing that nothing which follows matters.
No, the result i give you, is by knowing all the rules of the game from start, before doing anythings.
It is true that in reality you don’t have to bother tossing the coin when you get a 4, if you want to know if you win or not, if you get a 4, you have already lost.
Still, your probability to win, in my game, is 1/4, and not 2/7.
I gave the reasoning i follow steps by steps, and i give you a program to try it empirically.
I wait for you to give me you reasoning steps by steps, and a program to try it empirically.
Your program would reduce to the following program if a computer compiles it appropriately:
Code: Select all
INTEGER VARIABLE dice
INTEGER VARIABLE coin
INTEGER VARIABLE clock
INTEGER VARIABLE win
INTEGER VARIABLE wincount
INTEGER VARIABLE X
SUBROUTINE random {
clock = {Some Random program returning a number between 1 and 60}
return
}
SUBROUTINE roll {
clock = 0
Run random
clock = clock/10 as an Int
clock = clock + 1
dice = clock
return
}
SUBROUTINE toss {
clock = 0
clock = clock % 2
coin = clock
return
}
SUBROUTINE game {
win = 0
clock = 0
dice = 0
coin = 0
}
Run roll
If ((dice % 2) = 0) If (dice = 2) {Optional changes for efficiency in time}
Run toss
If (coin = 1)
win = 1
If (dice = 3)
win = 1
return
}
MAIN PROGRAM {
wincount = 0
X = 0
Until (X = 1000000) Do {
Run game
wincount = wincount + win
X = X + 1
}
Print "The wins are ", X/10000, "%."
End MAIN
}
The above program illustrates what you want for 1 million tries. I don't define the random generating program here except that it returns a value between 1 and 60. This is just a different program than yours so that I can relate and use it to show a simpler program that defines it different by perspective in what follows. This program presumes a total of 12 possibilities in which 3 of them are "wins" so the expected average results of replaying this game is 1/4 in practice. This respects all end
results (the 12) as valid by meaning.
But now for one "knowing" that the actual "wins" only occur only when the (dice = 2 & coin = 1) ["heads" for here] OR (dice = 3),
if we see this by the perspective of the ACTS, the program has to be redesigned to represent what one should expect about what one should
do. This is key in the Monty Hall Problem later because the probability is presented to suggest that you
should switch, which is an ACT, not the value of the RESULT. That is, you can get the same RESULT expected by only attending to your actions only here.
Here, at the beginning of your game, all you first require is to roll the dice. From the RESULTS of this role, you can predetermine which ones should count as determining how you should act to get what you want. Thus, you have,
1) when Dice roll = 1 [ACT: stop]
2 and 3) when Dice roll = 2 [ACT: Do Coin Toss]
. ..........................when Coin toss = Heads[ACT: stop]
. ..........................when Coin toss = Tails [ACT: stop]
4) when Dice roll = 3 [ACT: stop]
5) when Dice roll = 4 [ACT: stop]
6) when Dice roll = 5 [ACT: stop]
7) when Dice roll = 6 [ACT: stop]
These are all the possibilities based on ones' actions. Because the above (2) and (3) require you to follow through, these act as distinct and necessary actions dependent upon the act from a '2'. The code to demonstrate this is the same above with the change that is written to the right for the SUBROUTINE called, "game". This represents the efficiency to ACT. It also saves time by that procedure as it ignores the unessential steps that you include in (5) and (7) above. That is, it takes the processor less time by 2 x 2 = 4 unnecessary steps (of 12). Notice that the reason this is out of 7 above and NOT 8 is because this respects the perspective of complete actions one must DO from the perspective: What set of RESULTing behaviors that end on a "stop" that matters. Out of all "stop" ACTions, the probability is 2/7 because they respect the possible results with respect to their possible routes.
Notice that you may question whether this matters as you've predefined the game to require tossing the coin no matter what, right? However, you also added that we should be doing this multiple times and determine the occurrence of this probability ''true" by repeating it over and over through a constant process in the same duration. However, in real life, we may only get the fortune to playing such games once. And as such, it only saves the person playing (or computer running) to default to be efficient with the act. In the above program, the optional route I suggest, saves time even though the odds remain 1/4 by your defining process. If we use my alternative change, we save time per game. So we could actually do more games in the same time. This increases the total number of wins per unit of time possible to maximize your "wins" even given the same odds. if you only 'win' $1 for a winning game, while playing in time X, if you play 2 games in the same time, X, you increase your potential to win a maximum of $2. If the odds to win $1 is 1/4, of course the odds to win $2 is 1/4 * 1/4 = 1/16 in the same time.
It is this latter factor which demonstrates that you change the odds by playing multiple times anyways as it adds value for each attempt. So using this method (computer program) to test the validity of the experiment to interpret odds is moot. The question is whether you can improve your odds to win in any one game. And no matter which perspective you stage the game, there is none.
So let me show you a program which demonstrates the 2/7 probability works too:
Code: Select all
INTEGER VARIABLE dice
INTEGER VARIABLE clock
INTEGER VARIABLE win
INTEGER VARIABLE wincount
INTEGER VARIABLE X
SUBROUTINE random {
clock = {Some Random program returning a number between 1 and 70} {Notice change from 60 to 70}
return
}
SUBROUTINE roll {
clock = 0
Run random
clock = clock/10 as an Int
clock = clock + 1
dice = clock
return
}
SUBROUTINE game {
win = 0
clock = 0
dice = 0
Run roll
If (1 < dice < 5) {to allow for options 2, 3, & 4}
win = 1
return
MAIN PROGRAM {
wincount = 0
X = 0
Until (X = 1000000) Do {
Run game
wincount = wincount + win
X = X + 1
}
Print "The wins are ", X/10000, "%."
End MAIN
}
This respects the ACTs as relevant. If you were to play this same game only thinking in terms of your behavior, the reduction of the program based on it increases your odds to win more often if you were to maximize your efficiency in time for multiple plays. As such, you save time by simply skipping over having to toss the coins in those other cases from your original game.
AND, if you ignore even repeating games, then you have another perspective you have to consider for ONLY ONE game ignoring efficiency in time.
If you play only once, the odds are indeterminate until you finish the game. As such, when you "win", you won 100%. If you "lose" you win 0% of the time.
From the perspective of the one designing the game, they create the illusion of odds to be 2/7 OR 2/8 = 1/4. But nature is the one actually 'determining' the outcome regardless. And even using multiple world interpretations, the 2/7 probability would win out in this case as it is most efficient with respect to time. And by you forcing one to play out the game, if they "knew" and trusted you, they could accept the 1/4 probability even though it is actually 2/7 to nature. Only if you didn't inform them that they had to get the specified "wins" could you entice them to play out the game completely delaying their time on useless moves (such as when the dice is even & not '2') returning the odds to 1/4 by the perspective of the guest.
Did I blow your mind yet?