Hidden Bugs

Consider one solution to open_goat_door() from last week’s lab.

Note that we use an if-else structure to the code (or if-if as implemented here), to check what our initial selection is before returning the open door.

Also note that the criteria is exactly the same no matter which scenario we are in - we can’t open the door with the car, and we can’t open the current pick. Why do we care if the current pick is the car? Why not create a more general solution that works for both cases?

Note that we will always either have one or two doors available:

## [1] 3
## [1] 1 3
## [1] 1

Why does our function always work correctly when we first select the car?

##  [1] 1 3 1 1 3 3 1 3 1 3

But we end up with strange results when we first select a goat?

##  [1] 2 3 3 1 2 3 2 3 2 3

This is a problem! Our function now violates all of the rules by sometimes opening Door 2 with the car behind it, and sometimes opening Door 1, our current selection.

What is going on here???


Can anyone figure out the cause of this very subtle but very serious bug???

I will tell you that the logic of the above functions is correct.

Maybe look back to the stable solution that uses the if-else structure to test initial cases. Why would that fix the code? Which scenario appears to be problematic?


Bug Hunters

This bug demonstrates an important concept in computer science and unit testing - that of an edge case - an outcome that is usually the most extreme case possible so it is not properly considered in the code, and as a result functions break when then encounter them.

For example, if you make a payment on a bill and enter a negative number, do you receive a refund from the company?

If a user enters text into a numeric field, will that break the code?

Here is one example of such a case:

## [1] 5
## [1] 40
## [1] TRUE
## [1] FALSE

What happened???

Which edge case should we check for to ensure the code runs correctly here?