Monthly Archives: October 2020

Conditionals: Gambler: Questions

From page 28 on this pdf:
1. What is the “if (t == goal) wins++; ” keeping track of?
2. What does the outer loop control?
3. What happens at each trial?
4. What is the identifier “win” for?
5. What is the “stake” for?
6. What is the “goal” for?
7. How many trials would produce a good result?
8. How do you read the output in plain English?
% java Gambler 5 25 1000
203 wins of 1000

  1. If you were running this program to find the probability of winning in this game, what would need to be done to come up with the best approximation to the actual value?

a. Implement another loop that will increase the goal by doubling it at every iteration and report the conclusion. Keep all other variables fixed. The stake should be $5.

b. Implement another loop that will increase the trials by factors of 10 it at every iteration and report the conclusion. Keep all other variables fixed. The stake should be $5.

Challenge (Optional):

Add what is needed to be able to systematically increase both the goals and the trials. Report your result in full a sentence.

public class Gambler
{
    public static void main(String[] args)
   {
     int stake = Integer.parseInt(args[0]);
     int goal = Integer.parseInt(args[1]);
     int trials = Integer.parseInt(args[2]);

    int wins = 0;
    for (int i = 0; i < trials; i++)
     {
       int t = stake;
       while (t > 0 && t < goal)
        {
            if (Math.random() < 0.5) t++;
            else t--;
        }
        if (t == goal) wins++;
     }
   StdOut.println(wins + " wins of " + trials);  
   }
}

Conditionals: Gambler

The term gambler’s ruin is a statistical concept, most commonly expressed as the fact that a gambler playing a negative expected value game will eventually go broke, regardless of their betting system.

The original meaning of the term is that a persistent gambler who raises his bet to a fixed fraction of bankroll when he wins but does not reduce it when he loses, will eventually and inevitably go broke, even if he has a positive expected value on each bet.

Web-based app

 

Conditionals: The Crash of the AT&T Network in 1990



The Root Problem

The cause of the problem had come months before. In early December, technicians had upgraded the software to speed processing of certain types of messages. Although the upgraded code had been rigorously tested, a one-line bug was inadvertantly added to the recovery software of each of the 114 switches in the network. The defect was a C program that featured a break statement located within an if clause, that was nested within a switch clause.
In pseudocode, the program read as follows:

1  while (ring receive buffer not empty 
          and side buffer not empty) DO

2    Initialize pointer to first message in side buffer
     or ring receive buffer

3    get copy of buffer

4    switch (message)

5       case (incoming_message):

6             if (sending switch is out of service) DO

7                 if (ring write buffer is empty) DO

8                     send "in service" to status map

9                 else

10                    break

                  END IF

11           process incoming message, set up pointers to
             optional parameters

12           break
       END SWITCH


13   do optional parameter work