Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #15684 > unrolled thread

Re: Toughest Game Show Question

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Toughest Game Show Question Bill Reid <hormelfree@gmail.com> - 2012-01-10 06:47 -0800
    Re: Toughest Game Show Question tom st denis <tom@iahu.ca> - 2012-01-10 07:11 -0800
      Re: Toughest Game Show Question falk@rahul.net (Edward A. Falk) - 2012-01-11 00:05 +0000
    Re: Toughest Game Show Question Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-10 11:23 -0500
    Re: Toughest Game Show Question John Gordon <gordon@panix.com> - 2012-01-10 16:48 +0000
      Re: Toughest Game Show Question Seebs <usenet-nospam@seebs.net> - 2012-01-10 19:15 +0000
        Re: Toughest Game Show Question Keith Thompson <kst-u@mib.org> - 2012-01-10 13:27 -0800
          Re: Toughest Game Show Question James Kuyper <jameskuyper@verizon.net> - 2012-01-10 16:57 -0500
          Re: Toughest Game Show Question Seebs <usenet-nospam@seebs.net> - 2012-01-10 22:39 +0000
    Re: Toughest Game Show Question Stephen Sprunk <stephen@sprunk.org> - 2012-01-10 11:21 -0600
      Re: Toughest Game Show Question Bill Reid <hormelfree@gmail.com> - 2012-01-10 15:43 -0800
        Re: Toughest Game Show Question Stephen Sprunk <stephen@sprunk.org> - 2012-01-10 22:53 -0600
          Re: Toughest Game Show Question Seebs <usenet-nospam@seebs.net> - 2012-01-11 05:00 +0000
            Re: Toughest Game Show Question Kaz Kylheku <kaz@kylheku.com> - 2012-01-11 06:32 +0000
            Re: Toughest Game Show Question James Kuyper <jameskuyper@verizon.net> - 2012-01-11 07:22 -0500
        Re: Toughest Game Show Question falk@rahul.net (Edward A. Falk) - 2012-01-12 22:51 +0000
          Re: Toughest Game Show Question Ian Collins <ian-news@hotmail.com> - 2012-01-13 12:14 +1300
          Re: Toughest Game Show Question ImpalerCore <jadill33@gmail.com> - 2012-01-12 15:17 -0800
    Re: Toughest Game Show Question Shao Miller <sha0.miller@gmail.com> - 2012-01-10 14:33 -0500
    Re: Toughest Game Show Question Kaz Kylheku <kaz@kylheku.com> - 2012-01-11 01:44 +0000
      Re: Toughest Game Show Question Dann Corbit <dcorbit@connx.com> - 2012-01-10 23:48 -0800
        Re: Toughest Game Show Question James Kuyper <jameskuyper@verizon.net> - 2012-01-11 07:23 -0500
      Re: Toughest Game Show Question "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-11 14:33 +0100
        Re: Toughest Game Show Question Willem <willem@toad.stack.nl> - 2012-01-11 13:48 +0000
          Re: Toughest Game Show Question "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-11 18:44 +0100
            Re: Toughest Game Show Question Willem <willem@toad.stack.nl> - 2012-01-11 18:10 +0000
              Re: Toughest Game Show Question "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-11 19:23 +0100
            Re: Toughest Game Show Question James Kuyper <jameskuyper@verizon.net> - 2012-01-12 18:23 -0500
              Re: Toughest Game Show Question "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-15 19:03 +0100
              Re: Toughest Game Show Question Willem <willem@toad.stack.nl> - 2012-01-15 19:42 +0000
                Re: Toughest Game Show Question James Kuyper <jameskuyper@verizon.net> - 2012-01-15 16:57 -0500
                Re: Toughest Game Show Question Kaz Kylheku <kaz@kylheku.com> - 2012-01-16 04:16 +0000
                  Re: Toughest Game Show Question gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-16 12:14 +0000
                    Re: Toughest Game Show Question Bill Reid <hormelfree@gmail.com> - 2012-01-17 07:31 -0800
                  Re: Toughest Game Show Question Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-26 09:33 -0800
      Re: Toughest Game Show Question "BartC" <bc@freeuk.com> - 2012-01-12 21:07 +0000
        factor jgk@panix.com (Joe keane) - 2012-01-12 22:53 +0000
        Re: Toughest Game Show Question pete <pfiland@mindspring.com> - 2012-01-14 23:38 -0500

Page 2 of 2 — ← Prev page 1 [2]

#15730

In article <20120110171743.392@kylheku.com>, kaz@kylheku.com says...
[snip]
Yeah, but what it you happen to *want* the goat?

[toc] | [prev] | [next] | [standalone]

#15745

On 01/11/2012 02:48 AM, Dann Corbit wrote:
> In article <20120110171743.392@kylheku.com>, kaz@kylheku.com says...
> [snip]
> Yeah, but what it you happen to *want* the goat?

That's easy - switch to the door opened by the Host.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#15749

Am 11.01.2012 02:44, schrieb Kaz Kylheku:
> On 2012-01-10, Bill Reid <hormelfree@gmail.com> wrote:
>> On Jan 9, 8:56 pm, divya bisht <bisht88.di...@gmail.com> wrote:
>>>
>>> You are on a game show and there are three doors. The presenter tells
>>> you that behind one of doors there is a car and behind the other two
>>> are goats, if you pick the car you win it. After you have picked a
>>> door the presenter opens a different door with a goat behind it, he
>>> then gives you the chance to change what door you open, what should
>>> you do?
>>>
>> OH NO, THE DREADED "MONTY HALL" PROBLEM, IT'S BEEN AT LEAST A
>> DECADE SINCE I'VE SEEN THIS MONSTROUSITY REAR IT'S UGLY HEAD IN
>> USENET!!!!!!!
>>
>> The answer is that it doesn't matter, your odds are still one
>> in three no matter what you do...but wait, does it matter if the
>> presenter knows what's behind the doors and shows you the goat
>> to make the game more interesting?  Let's see what happens with
>> the "regs" here, might be fun...
> 
> I think you an easily solve this by a simple division into cases,
> and simple probabilities.
> 
> Look Ma, no conditional probability, no Bayes' theorem.
> 
> 
> Suppose Monty always reveals the goat. (This builds suspense in the
> audience and is good for the show's ratings, which are more important
> than whether or not cars are given away.)
> 
> 
> There are two cases:
> 
> Case 1: (p = 2/3) You picked the goat.
> 
> Monty knows that this case is occurring, and reveals to you the other goat! So
> you must switch to get the car, and by switching the car is guaranteed.
> 
> Case 2: (p = 1/3) You picked the car.
> 
> In this case, you must not switch; you're already on the car.
> Of course Monty reveals a goat in this case also.
> 
> 
> Now you don't know which of these cases you are in. But you do know
> that one of these cases requires switching and the other requires
> staying and that the one that requires switching occurs with p = 2/3, and the
> one that requires staying occurs with p = 1/3.
> 
> This essentially translates to "the probability that you must switch in order
> to win the car is 2/3", and that translates to "the probability that
> the car is behind the door you did not pick in round 1 is 2/3".
> 
> If you do not switch, you are betting on being in Case 2, which is p = 1/3: the
> same odds as a one-round draw.
> 
> If you switch, you are betting that you are in Case 1, where you have p = 2/3
> odds, an improvement.
> 
> 
> 
> Switching: no brainer.

My simulation shows that by switching your total chance to win
the car is 1/2 or probability 0.5

I think this is true, due to the fact that by switching you might
go off the car choice.

/Str

[toc] | [prev] | [next] | [standalone]

#15750

M. Strobel wrote:
) My simulation shows that by switching your total chance to win
) the car is 1/2 or probability 0.5

How did you do the simulation?

Here's how I did it:

1 - Randomly pick a door for the car.
2 - Randomly pick a door for the contestant.
3 - Randomly pick one of the remaining two doors for the host.
3a - If that contains a car, pick the other remaining one for the host.
4 - Look at the door that neither the host nor the contestant picked.
5 - Score a win if that door is the door from step 1.

And my simulation ends up with 2/3 wins and 1/3 losses.


So, could you describe the steps in your simulation?


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#15758

Am 11.01.2012 14:48, schrieb Willem:
> M. Strobel wrote:
> ) My simulation shows that by switching your total chance to win
> ) the car is 1/2 or probability 0.5
> 
> How did you do the simulation?
> 
> Here's how I did it:
> 
> 1 - Randomly pick a door for the car.
> 2 - Randomly pick a door for the contestant.
> 3 - Randomly pick one of the remaining two doors for the host.
> 3a - If that contains a car, pick the other remaining one for the host.
> 4 - Look at the door that neither the host nor the contestant picked.
> 5 - Score a win if that door is the door from step 1.
> 
> And my simulation ends up with 2/3 wins and 1/3 losses.
> 
> 
> So, could you describe the steps in your simulation?
> 
> 
> SaSW, Willem

Well, I do it with minimal abstraction in a list of 2 goats and
one car.

1 generate list by changing one of (goat goat goat) to car
2 player randomly picks element
2 moderator discloses one goat (not picked)
3 player changes / does not change

this all wrapped up in procedures, accounting only for the results.

Just can't find any errors there.

FWIW the code in Tcl is on http://pastebin.com/r6cZBET0
Oh my god, it is so OT! Let my post die in peace and don't waste your time if you
don't want to.

/Str.

[toc] | [prev] | [next] | [standalone]

#15759

M. Strobel wrote:
) Well, I do it with minimal abstraction in a list of 2 goats and
) one car.
)
) 1 generate list by changing one of (goat goat goat) to car
) 2 player randomly picks element
) 2 moderator discloses one goat (not picked)
) 3 player changes / does not change
)
) this all wrapped up in procedures, accounting only for the results.
)
) Just can't find any errors there.

I think I can find at least one error, even though I don't speak TCL:

...
 while {$gofindit} {
   set zi [zerototwo]
   if {($zi != $pick) && ([lindex $alpha $zi]=="goat") } {
     set gofindit false
   } else {
     set pick [zerototwo]   #<--- What is this doing here ??
   }
 }
...

By resetting pick in that loop, you make it more likely that 'pick' will be
a car after the loop.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#15760

Am 11.01.2012 19:10, schrieb Willem:
> M. Strobel wrote:
---cut
> ) Just can't find any errors there.
> 
> I think I can find at least one error, even though I don't speak TCL:
> 
> ...
>  while {$gofindit} {
>    set zi [zerototwo]
>    if {($zi != $pick) && ([lindex $alpha $zi]=="goat") } {
>      set gofindit false
>    } else {
>      set pick [zerototwo]   #<--- What is this doing here ??
>    }
>  }
> ...
> 
> By resetting pick in that loop, you make it more likely that 'pick' will be
> a car after the loop.
> 
> 
> SaSW, Willem

Oh, have to check it, will be back later. I thought Tcl was rather easy to read.

/Str.

[toc] | [prev] | [next] | [standalone]

#15791

On 01/11/2012 12:44 PM, M. Strobel wrote:
> Am 11.01.2012 14:48, schrieb Willem:
>> M. Strobel wrote:
>> ) My simulation shows that by switching your total chance to win
>> ) the car is 1/2 or probability 0.5
>>
>> How did you do the simulation?
>>
>> Here's how I did it:
>>
>> 1 - Randomly pick a door for the car.
>> 2 - Randomly pick a door for the contestant.
>> 3 - Randomly pick one of the remaining two doors for the host.
>> 3a - If that contains a car, pick the other remaining one for the host.
>> 4 - Look at the door that neither the host nor the contestant picked.
>> 5 - Score a win if that door is the door from step 1.
>>
>> And my simulation ends up with 2/3 wins and 1/3 losses.
>>
>>
>> So, could you describe the steps in your simulation?
>>
>>
>> SaSW, Willem
> 
> Well, I do it with minimal abstraction in a list of 2 goats and
> one car.
> 
> 1 generate list by changing one of (goat goat goat) to car
> 2 player randomly picks element
> 2 moderator discloses one goat (not picked)
> 3 player changes / does not change
> 
> this all wrapped up in procedures, accounting only for the results.
> 
> Just can't find any errors there.
> 
> FWIW the code in Tcl is on http://pastebin.com/r6cZBET0
> Oh my god, it is so OT! Let my post die in peace and don't waste your time if you
> don't want to.

Your simulation is needlessly complicated:


#include <limits.h>
#include <stdio.h>
#include <stdlib.h>

static int choose3(void)
{
    int r;
    // max is the largest multiple of 3 that is less than or equal to
    // RAND_MAX+1
    static const int max = 3*((RAND_MAX + 1UL)/3);

    // This removes the bias that would otherwise exist due if
    // max != RAND_MAX+1
    while((r=rand())>= max);

    return r/(max/3);
}

#define TRIAL_RUNS ULONG_MAX
int main(void)
{
    srand(12345);
    unsigned long keep = 0;
    unsigned long change = 0;
    for(unsigned long i=TRIAL_RUNS; i; i--)
    {
        int car = choose3();
        int guess = choose3();
        if(guess == car)// Host chooses one of the other doors.
            keep++;     // Sticking with your original choice wins.
        else            // Host chooses the other door with the goat.
            change++;   // Switching to the remaining door wins.
    }
    printf("%lu runs. Keeping wins %lu=%g%%; switching wins %lu=%g%%\n",
        TRIAL_RUNS, keep, (double)keep/TRIAL_RUNS,
        change, (double)change/TRIAL_RUNS);
    return 0;
}

[toc] | [prev] | [next] | [standalone]

#15828

Am 13.01.2012 00:23, schrieb James Kuyper:
> On 01/11/2012 12:44 PM, M. Strobel wrote:
>> Am 11.01.2012 14:48, schrieb Willem:
>>> M. Strobel wrote:
>>> ) My simulation shows that by switching your total chance to win
>>> ) the car is 1/2 or probability 0.5
>>>
>>> How did you do the simulation?

---cut

>>
>> Just can't find any errors there.
>>
>> FWIW the code in Tcl is on http://pastebin.com/r6cZBET0
>> Oh my god, it is so OT! Let my post die in peace and don't waste your time if you
>> don't want to.
> 
> Your simulation is needlessly complicated:
> 

Oh yes. I tried a didactic programming style, but shot myself in the leg somehow.

/Str.

[toc] | [prev] | [next] | [standalone]

#15830

James Kuyper wrote:
) Your simulation is needlessly complicated:
 <snip>
)         int car = choose3();
)         int guess = choose3();
)         if(guess == car)// Host chooses one of the other doors.
)             keep++;     // Sticking with your original choice wins.
)         else            // Host chooses the other door with the goat.
)             change++;   // Switching to the remaining door wins.

Your solution does not replicate the actual circumstances, I.E. it uses
some of the logic steps that are used to prove the 1/3 result, to simplify
the code.  People who do not believe the proof will likely also not believe 
results from your program.

Of course, you can optimize a simulation.  But the point is that any
optimizing step is essentially one of the steps from the mathematical
proof (that shows that you should switch), so it cannot be used to
convince anybody that doesn't follow the proof.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#15834

On 01/15/2012 02:42 PM, Willem wrote:
> James Kuyper wrote:
> ) Your simulation is needlessly complicated:
>  <snip>
> )         int car = choose3();
> )         int guess = choose3();
> )         if(guess == car)// Host chooses one of the other doors.
> )             keep++;     // Sticking with your original choice wins.
> )         else            // Host chooses the other door with the goat.
> )             change++;   // Switching to the remaining door wins.
> 
> Your solution does not replicate the actual circumstances, I.E. it uses
> some of the logic steps that are used to prove the 1/3 result, to simplify
> the code.  People who do not believe the proof will likely also not believe 
> results from your program.

If you could identify those logic steps, I could complicate the code to
demonstrate their validity. The best-known statement of the problem is
the one from Marilyn vos Savant's "Ask Marilyn" column on page 16 of the
1990-09-09 Parade magazine, and her answer was based on many unstated
assumptions, that strike me as quite reasonable - but a fair fraction of
those who disagreed with her made different assumptions. The problem was
originally posed in a letter by Steve Selvin to the American
Statistician in 1975, but I haven't seen a copy of that letter, so I'm
not sure if it contained the same assumptions.

My program was meant to simulate the standard version of the problem,
with all such assumptions stated explicitly, as specified in
http://www.usd.edu/~xtwang/Papers/MontyHallPaper.pdf. Anyone who objects
to my program because they made different assumptions is, of course,
correct: the original problem was under-specified.

I'm not sure how I should modify the program to make it's validity as a
simulation of the fully-specified problem more obvious. Here's an
attempt. I relies upon a user-defined function:

	extern int host_choose_goad(int car, int guess);

This function's two arguments are supposed to each have values of 0, 1,
2; it's behavior if that is not the case is irrelevant. It must not
contain any feature which renders the behavior of the program as a whole
undefined, if passed valid arguments. It must return. It's return value
must be either 0, 1, or 2, and must not be equal to either of its two
arguments. Therefore, if the two arguments are not equal, there is only
one unique return value permitted. Otherwise it must choose between
exactly two possibilities; how it makes that choice is completely
irrelevant. It must do nothing to interfere with the randomness of the
numbers returned by choose3() below, for instance by calling srand().
Here's the rest of the main program:

#include <assert.h>
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>

static int choose3(void)
{
    int r;
    // max is the largest multiple of 3 that is less than or equal to
    // RAND_MAX+1
    static const int max = 3*((RAND_MAX + 1UL)/3);

    // This removes the bias that would otherwise exist due if
    // max != RAND_MAX+1
    while((r=rand())>= max);

    return r/(max/3);
}

#define TRIAL_RUNS ULONG_MAX
int main(void)
{
    srand(12345);
    unsigned long keep = 0;
    unsigned long change = 0;
    for(unsigned long i=TRIAL_RUNS; i; i--)
    {
        int car = choose3();
        int guess = choose3();
        int goat = host_chooses_goat(car, guess);

	assert(0 <= goat < 3);
	assert(goat != car && goat != guess);

        // If those assertions succeed, this expression gives the
	// number of the only remaining unchosen door
	int changed_guess = 3-(guess+goat);

        if(guess == car)
            keep++;     // Keeping your original guess wins.
        else if(changed_guess == car)
            change++;   // Changing your guess wins.
    }
    printf("%lu runs. Keeping wins %lu=%g%%; switching wins %lu=%g%%\n",
        TRIAL_RUNS, keep, (double)keep/TRIAL_RUNS,
        change, (double)change/TRIAL_RUNS);
    return 0;
}

The key logic issue is that, if host_chooses_goat() satisfies the
requirements placed upon it, and if the second condition gets evaluated,
that condition is guaranteed to evaluate to 1. As as result, the second
condition can be optimized away,, rendering host_chooses_goat()
irrelevant, which is how I generated my original version of the code.

> Of course, you can optimize a simulation.  But the point is that any
> optimizing step is essentially one of the steps from the mathematical
> proof (that shows that you should switch), so it cannot be used to
> convince anybody that doesn't follow the proof.

Is this version sufficient?
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#15839

On 2012-01-15, Willem <willem@toad.stack.nl> wrote:
> James Kuyper wrote:
> ) Your simulation is needlessly complicated:
> <snip>
> )         int car = choose3();
> )         int guess = choose3();
> )         if(guess == car)// Host chooses one of the other doors.
> )             keep++;     // Sticking with your original choice wins.
> )         else            // Host chooses the other door with the goat.
> )             change++;   // Switching to the remaining door wins.
>
> Your solution does not replicate the actual circumstances, I.E. it uses
> some of the logic steps that are used to prove the 1/3 result, to simplify
> the code.  People who do not believe the proof will likely also not believe 
> results from your program.

People who do not believe the proof are going to be too ignorant to understand
whether a computer program is sound or not (but pretend otherwise), so it
doesn't matter.

[toc] | [prev] | [next] | [standalone]

#15846

In article <20120115201045.131@kylheku.com>,
Kaz Kylheku  <kaz@kylheku.com> wrote:
...
>People who do not believe the proof are going to be too ignorant to understand
>whether a computer program is sound or not (but pretend otherwise), so it
>doesn't matter.

Good point.  It's the old "You can't fix stupid".

Anyway, to change the topic slightly...

Is it known whether or not the host will *always* give you the choice
(chance) to switch?  That seems to me to be critical in deriving the
standard answer to this question (*).  Suppose the host employs the strategy
of offering you the choice only if you have the car.  I.e., if you have a
goat, then you're stuck with it (**).  In this case, it would be obvious
that you should *not* switch.

(*) That you should always switch.
(**) And he "wins".

-- 
They say compassion is a virtue, but I don't have the time!

    - David Byrne -

[toc] | [prev] | [next] | [standalone]

#15887

On Jan 16, 4:14 am, gaze...@shell.xmission.com (Kenny McCormack)
wrote:
> In article <20120115201045....@kylheku.com>,
> Kaz Kylheku  <k...@kylheku.com> wrote:
> ...
>
> >People who do not believe the proof are going to be too ignorant to understand
> >whether a computer program is sound or not (but pretend otherwise), so it
> >doesn't matter.
>
> Good point.  It's the old "You can't fix stupid".
>
> Anyway, to change the topic slightly...
>
> Is it known whether or not the host will *always* give you the choice
> (chance) to switch?  That seems to me to be critical in deriving the
> standard answer to this question (*).  Suppose the host employs the strategy
> of offering you the choice only if you have the car.  I.e., if you have a
> goat, then you're stuck with it (**).  In this case, it would be obvious
> that you should *not* switch.
>
> (*) That you should always switch.
> (**) And he "wins".
>
You're right, you can't fix stupid, most pertinently since I posted
the exact same scenario as you did a few days ago...

---
William Ernest Reid

[toc] | [prev] | [next] | [standalone]

#16264

Kaz Kylheku <kaz@kylheku.com> writes:

> On 2012-01-15, Willem <willem@toad.stack.nl> wrote:
>> James Kuyper wrote:
>> ) Your simulation is needlessly complicated:
>> <snip>
>> )         int car = choose3();
>> )         int guess = choose3();
>> )         if(guess == car)// Host chooses one of the other doors.
>> )             keep++;     // Sticking with your original choice wins.
>> )         else            // Host chooses the other door with the goat.
>> )             change++;   // Switching to the remaining door wins.
>>
>> Your solution does not replicate the actual circumstances, I.E. it uses
>> some of the logic steps that are used to prove the 1/3 result, to simplify
>> the code.  People who do not believe the proof will likely also not believe 
>> results from your program.
>
> People who do not believe the proof are going to be too ignorant to understand
> whether a computer program is sound or not (but pretend otherwise), so it
> doesn't matter.

I disagree with the thesis:  I think it depends on the program,
not just the person.  Also there are different skill sets
involved -- it's easy to imagine someone having difficulty
following a proof (considering how many really horrible proofs
have been published) but who still could follow program logic,
especially if the program were carefully written with that in
mind.

[toc] | [prev] | [next] | [standalone]

#15787

"Kaz Kylheku" <kaz@kylheku.com> wrote in message 
news:20120110171743.392@kylheku.com...
> On 2012-01-10, Bill Reid <hormelfree@gmail.com> wrote:
>> On Jan 9, 8:56 pm, divya bisht <bisht88.di...@gmail.com> wrote:
>>>
>>> You are on a game show and there are three doors. The presenter tells
>>> you that behind one of doors there is a car and behind the other two
>>> are goats, if you pick the car you win it. After you have picked a
>>> door the presenter opens a different door with a goat behind it, he
>>> then gives you the chance to change what door you open, what should
>>> you do?

> I think you an easily solve this by a simple division into cases,
> and simple probabilities.

I found it easier to think of a million doors instead of three.

You choose one door (obviously with 1/1000000 probability of choosing the 
one with the prize).

The host then opens 999,998 of the remaining 999,999 doors. One door stays 
closed.

Which of the two closed doors (the one you chose at random, and the one 
that's deliberately left by the host) is more likely to have the prize 
behind it?

-- 
Bartc
 

[toc] | [prev] | [next] | [standalone]

#15789 — factor

#include <stdio.h>
#include <math.h>


int main(int argc, char **argv)
{
    const char *arg;
    unsigned long ori;
    unsigned long red;
    unsigned long div;
    unsigned long ste;

    if (argc != 2)
    {
	fputs("usage: factor <number>\n", stderr);
	return 1;
    }

    arg = argv[1];
    sscanf(arg, "%lu", &ori);
    red = ori;
    fprintf(stdout, "%lu", ori);
    fputs(" = ", stdout);

    if (red < 4)
    {
	fputc('0' + (int) red, stdout);
	goto done;
    }

    if ((red & 0x1) == 0x0)
    {
	red >>= 1;
	fputc('2', stdout);

	if ((red & 0x1) == 0x0)
	{
	    int x;

	    fputc('^', stdout);
	    red >>= 1;
	    x = 2;

	    while ((red & 0x1) == 0x0)
	    {
		red >>= 1;
		x++;
	    }

	    fprintf(stdout, "%d", x);
	}

	if (red == 1)
	    goto done;

	fputc('*', stdout);
    }

    if (red % 3 == 0)
    {
	fputc('3', stdout);
	red /= 3;

	if (red % 3 == 0)
	{
	    int x;

	    red /= 3;
	    fputc('^', stdout);
	    x = 2;

	    while (red % 3 == 0)
	    {
		red /= 3;
		x++;
	    }

	    fprintf(stdout, "%d", x);
	}

	if (red == 1)
	    goto done;

	fputc('*', stdout);
    }

    div = 5;
    ste = 2;

    for (;;)
    {
	unsigned long lim;

    relim:
	lim = (unsigned long) floor(sqrt((double) red));

	for (;;)
	{
	    if (red % div == 0)
	    {
		red /= div;
		fprintf(stdout, "%lu", div);

		if (red % div == 0)
		{
		    int x;

		    fputc('^', stdout);
		    red /= div;
		    x = 2;

		    while (red % div == 0)
		    {
			red /= div;
			x++;
		    }

		    fprintf(stdout, "%d", x);
		}

		if (red == 1)
		    goto done;

		fputc('*', stdout);
		goto relim;
	    }

	    div += ste;
	    ste ^= 6;

	    if (div > lim)
	    {
		fprintf(stdout, "%lu", red);
		goto done;
	    }
	}
    }

  done:
    fputc('\n', stdout);
    fflush(stdout);
    return 0;
}

[toc] | [prev] | [next] | [standalone]

#15808

BartC wrote:
> 
> "Kaz Kylheku" <kaz@kylheku.com> wrote in message
> news:20120110171743.392@kylheku.com...
> > On 2012-01-10, Bill Reid <hormelfree@gmail.com> wrote:
> >> On Jan 9, 8:56 pm, divya bisht <bisht88.di...@gmail.com> wrote:
> >>>
> >>> You are on a game show and there are three doors.
> >>> The presenter tells
> >>> you that behind one of doors there is a car
> >>> and behind the other two
> >>> are goats, if you pick the car you win it. After you have picked a
> >>> door the presenter opens a different door
> >>> with a goat behind it, he
> >>> then gives you the chance to change what door you open,
> >>> what should you do?
> 
> > I think you an easily solve this by a simple division into cases,
> > and simple probabilities.
> 
> I found it easier to think of a million doors instead of three.
> 
> You choose one door
> (obviously with 1/1000000 probability of choosing the
> one with the prize).
> 
> The host then opens 999,998 of the remaining 999,999 doors.
> One door stays closed.
> 
> Which of the two closed doors 
> (the one you chose at random, and the one
> that's deliberately left by the host) is more likely to have the prize
> behind it?

That's the way that I think of it also.

-- 
pete

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web