The scams of Statistics...

[Obvious Leo]

As I suspected there might be there is a Monty Hall game running on the internet.

As of now 278,324 contestants decided to stay with their first choice and won a total of 93,286 pretend cars, a success rate of just below 34%

168,244 contestants decided to change their choice and won a total of 111,535 pretend cars, a total of 66%.

Scott. Would you care to name the parties responsible for staging such a massive global conspiracy or would you prefer to apologise to the members of this forum for treating them like morons.

[Obvious Leo]

Scott. I assume you can see what the problem is here. It is an empirical FACT that players who switch their guess in the Monty Hall game double their chance of winning. This cannot be altered.

[Obvious Leo]

Why don't you try it on yourself with a coin under a cup? Try 50 guesses to stay with your first choice and then 50 guesses to switch and this should be statistically significant. I'll bet you every penny I own that you'll prove yourself wrong.

[Scott Mayers]

Why don't you try it on yourself with a coin under a cup? Try 50 guesses to stay with your first choice and then 50 guesses to switch and this should be statistically significant. I'll bet you every penny I own that you'll prove yourself wrong.

The onus now is on you. Provide the damn links you are asserting is 'true'. AND explain how or why you believe an empirical experiment regarding ANY probability can be interpreted as ever sufficient as evidence! Do you think it impossible for one to win a lottery two or more times in a row regardless of the odds against it? How about the odds that someone could toss a heads 100 times in a row?

I also ask you how you could infer that induction should ever be more significant than a deductive argument? Do you think a theory is more superior to a theorem?

[dionisos]

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.

Show me the 12 possibilities, i only see 9.

Here you flip a coin, and even if you had removed some steps, the probability to win would still be 1/4:

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]

In your program you don’t.

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
	}

How you program could be equivalent of my game if you never flip a coin ?.
This is a essential part, if you get a 2 you should flip a coin.

Run roll
If (1 < dice < 5) {to allow for options 2, 3, & 4}
win = 1
return

This is simply not the condition to win, you don’t win on 2, 3, or 4, you win on 2 and head, or 3.

[mickthinks]

Scott. I'm hoisting the white flag and retiring from the battlefield. I did my best.

Leo, I thought that was a sensible and honourable retreat, so I am wondering why you have come back?

[Scott Mayers]

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
	}

...

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?

Here you flip a coin, and even if you had removed some step, the probability to win would still be 1/4:

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]

In your program you don’t.

Which 'program'? The first or the second? If you're referring to the second, NO, I numbered them above. The "ACT: Do Coin Toss", is an entry point to both "head" and "tail" outcomes here. The relative comparison is from the beginning of the dice roll to the "ACT:stop".

How you program could be equivalent of my game if you never flip a coin ?.
This is a essential part, if you get a 2 you should flip a coin.

Run roll
If (1 < dice < 5) {to allow for options 2, 3, & 4}
win = 1
return

This is simply not the condition to win, you don’t win on 2, 3, or 4, you win on 2 and head, or 3.

No, the numbered above refers (3 and 4) together as the point that determines the coin tosses. My second program reduces the need to represent this as a coin toss even though it is. This is because all that matters is the ACT, not the inclusion of those events that can be eliminated ((5) and (7) above).

So all I need to allow the (2 & Heads) OR the '3' is the steps (not the value of the Dice rolls) above.

[Obvious Leo]

Scott. I'm hoisting the white flag and retiring from the battlefield. I did my best.

Leo, I thought that was a sensible and honourable retreat, so I am wondering why you have come back?

You're quite right, mick. This is doing my head in and I should know better.

[mickthinks]

Scott: If you play only once, the odds are indeterminate until you finish the game.

I don't understand what you mean by "indeterminate" here, Scott. Do you mean "having a fixed value that is impossible to calculate", do you mean "having no fixed value", or do you mean something else? I think this may lie close to the root of the problem you are having reconciling your ideas with dionisos's, Leo's and mine.

[dionisos]

Scott Mayers,

I was speaking about your second program.
Do you understand that, by doing what you do, you change the game ?

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]

Here you have 7 NOT equiprobable possibilities, and you will have 1/4 to win, like in my game.

By doing it:

Code: Select all

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
   }

But here you have 7 equiprobable possibilities.

This two things are NOT equivalent at all, your second program, and the thing i quoted with the [act], are not equivalent at all.
Do you understand that ?

Also, could you enumerate me the 12 possibilities in your first program, i only see 9 possibilities.

[Scott Mayers]

Scott: If you play only once, the odds are indeterminate until you finish the game.

I don't understand what you mean by "indeterminate" here, Scott. Do you mean "having a fixed value that is impossible to calculate", do you mean "having no fixed value", or do you mean something else? I think this may lie close to the root of the problem you are having reconciling your ideas with dionisos's, Leo's and mine.

If I presented a box to you without you being able to see inside it, it is indeterminate to you. This just means that you have no idea whether something is in it or nothing....or any other possible different something of any sort until you open it to determine it. Also, because we are discussing possibilities and probabilities, for some cases you can have no means to validate it for certain.

The odds to play a game once is like buying a lotto ticket given some odds. In such a case, you may also be indeterminate even being told of the supposed odds since it could be rigged. Having trust in the fairness is not sufficient enough to determine if the odds are fair.

And lastly, on the issue of those spaces/doors which are equal to zero, you can't determine necessarily whether you can use 0/3 or 0/4 to represent the second places when you happen to have initially picked the car. That is my mention above with
(0 + 1 + 1)/3 or (0 + 0 + 1 + 1)/4. This is where I see the error.

Look back to see the last diagrams. The first of two shows the original assumption in the puzzle and my recreation of it below. See viewtopic.php?f=26&t=16671&start=135#p220875, the particular post on page 10.

[Scott Mayers]

Scott Mayers,

I was speaking about your second program.
Do you understand that, by doing what you do, you change the game ?

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]

Here you have 7 NOT equiprobable possibilities, and you will have 1/4 to win, like in my game.

By doing it:

Code: Select all

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
   }

You have 7 equiprobable possibilities.

This two things are NOT equivalent at all.
Do you understand that ?

Also, could you enumerate me the 12 possibilities in you first program, i only see 9 possibilities.

The possibilities are 12 in the first case because the dice rolls for 6 options of which the case in the even add 3 (one for each even number.)

They are so with respect to the player. But you should be able to see the point of this as samples to demonstrate how the programs can be redesigned to favor one perspective over another. I don't prefer your example as you force me to use as it is even more dissociated from the Monty Hall Problem. I understand your reference that some things are not equiprobable. So now apply this in what I post after this. See viewtopic.php?f=26&t=16671&start=135#p220875. There you see in the actual puzzle how they are equiprobable = 0. And so your concern on this case is sidelining and irrelevant. See the other comments I had mentioned already three times in this thread.

The question is whether when the car is picked, if the host has only one or two distinct options. Since they both equal zero as a probability, when you add them, the mistake occurs by their averages.

Again,
You and others presume the Result is what counts, not the Acts. The result when the values are zeros are treated as if they are one incident when they are two.
[0 + 1 + 1]/3 = 0/3 + 2/3 = 2/3 (the error)

[0 + 0 + 1 + 1]/4 = 0/4 + 0/4 + 1/4 + 1/4 = 2/4 = 1/2 (the appropriate answer)

[dionisos]

The possibilities are 12 in the first case because the dice rolls for 6 options of which the case in the even add 3 (one for each even number.)

6+3=9 no ?

[dionisos]

But you should be able to see the point of this as samples to demonstrate how the programs can be redesigned to favor one perspective over another.

No, like i explained, what you show with the seven not equiprobable cases, are simply not the same that what your program do.

You can consider only 7 possibilities if you want, but you should toss the coin to create two of the 7 possibilities.

[dionisos]

I understand your reference that some things are not equiprobable

Show me a simple example where the possibilities are not equiprobable, for me to confirm that you understand what it mean.