Math Not Required

Let's examine a problem that we could math our way out of, but assume we don't know how. We'll lean on our programming to teach us what we don't know.

The Monty Hall problem comes from an old game show called Let's Make a Deal, hosted by Monty Hall. In the show, Monty would show three closed doors to a contestant and explain that one holds a car while the other two hold goats. The contestant then chose a door. After this first pick, Monty would reveal one unchosen door that was hiding a goat. The contestant then faced a key second choice: keep their door or switch to the other closed door. After this final choice, the two doors were opened and the contestant kept whatever they selected. The goal, of course, was to win a car.

What we really to want to know: are the chances of winning better if we switch or don't switch after the reveal?

Let's see if we can find out by modeling the problem in code:

  defmodule MontyHallProblem do
    def dont_switch do
      Enum.at(randomize_doors(), pick_door())
      # no need to model the reveal or second choice in this case since it
      # doesn't change the outcome
    end

    def switch do
      game = randomize_doors()
      pick1 = pick_door()

      reveal =
        0..2
        |> Enum.filter(fn i -> i != pick1 and Enum.at(game, i) == :lose end)
        |> Enum.random()

      pick2 = hd([0, 1, 2] -- [pick1, reveal])
      Enum.at(game, pick2)
    end

    defp randomize_doors, do: Enum.shuffle(~w[win lose lose]a)

    defp pick_door, do: Enum.random(0..2)
  end

Hopefully this code is a pretty direct translation of the earlier problem description. Note that we now have two public functions, one that simulates a game where we switch and another for when we don't.

Here's a random run of each one:

  MontyHallProblem.dont_switch() |> IO.inspect()

:win

  MontyHallProblem.switch() |> IO.inspect()

:lose

Now what we want to do is just try them both—a lot—and show the results.

Let's write a little code for that too:

  defmodule MonteCarloSimulation do
    def analyze(event, measurement, repetitions \\ 10_000) do
      Stream.repeatedly(event)
      |> Stream.take(repetitions)
      |> Enum.count(fn result -> result == measurement end)
      |> then(&:io_lib.format("~.2f%", [&1 / repetitions * 100]))
      |> to_string()
    end
  end

This code takes some function that simulates an event, runs it for a requested number repetitions, and counts how many times the result matches a provided measurement. The rest is just about showing pretty output.

You may have noticed from the module name that this technique is another "Monte." Monte Carlo simulations are just repeated random samplings used to measure results. This works thanks to the law of large numbers.

It may sound like I'm sneaking some math into this solution, but I suspect most of us intuitively understand this process even if we don't know the names for it. For example, how many heads will I get if I flip a coin three times?

  MonteCarloSimulation.analyze(
    fn -> Enum.random([:heads, :tails]) end,
    :heads,
    3
  )

"0.00%"

I guess I'm not very lucky, but watch what happens if I keep cranking up the number of flips:

  MonteCarloSimulation.analyze(
    fn -> Enum.random([:heads, :tails]) end,
    :heads,
    30
  )

"43.33%"

  MonteCarloSimulation.analyze(
    fn -> Enum.random([:heads, :tails]) end,
    :heads,
    300
  )

"54.67%"

  MonteCarloSimulation.analyze(
    fn -> Enum.random([:heads, :tails]) end,
    :heads,
    3_000
  )

"50.47%"

  MonteCarloSimulation.analyze(
    fn -> Enum.random([:heads, :tails]) end,
    :heads,
    30_000
  )

"50.40%"

What if I asked: how many heads will I get if I flip 30,000 coins? I feel like a lot of folks would answer, "around 15,000," or, "about half." That's exactly what happens. The more tests we do the more the results converge on the expected probability.

We can use that to discover the answer to the Monty Hall problem!

  %{
    "Don't switch win chance" =>
      MonteCarloSimulation.analyze(
        &MontyHallProblem.dont_switch/0,
        :win
      ),
    "Switch win chance" =>
      MonteCarloSimulation.analyze(
        &MontyHallProblem.switch/0,
        :win
      )
  }

%{"Don't switch win chance" => "33.40%", "Switch win chance" => "66.78%"}

What we see there is mathematically correct, or at least very close to it. The don't switch result is probably the easiest to come to terms with. We selected one of three available doors and never changed, so we'll be right about a third of the time.

The switching result is a little trickier. If our initial guess is right a third of the time, that means it's wrong two thirds of the time. Put another way there's a two thirds chance that the car is behind one of the two doors we didn't initially pick. Then Monty is kind enough to rule one of those two out, shifting the full two thirds chance to the one remaining unselected door. If we switch to that one, we double our chances to win!

Programming can show you what to do, even if it doesn't explain why.

I want to be very clear: this article is examining whether or not math is essential background knowledge for programmers. It is not arguing that math is not important or valuable.

I believe that most people can benefit from learning some math! You are absolutely affected by math in your day-to-day life, whether you understand it or not.

For example, many adults have a credit card. Credit cards typically come with an Annual Percentage Rate (APR), which is pretty confusing since most cards calculate daily compound interest. Compound interest could be considered the eighth wonder of the modern world and, when you compound it daily, it's simply terrifying. It's vital to understand at least the magnitude of how this grows if you carry a significant balance.

However, if you don't know this, programming might be able to save you! Let's build a model for credit cards:

  defmodule CreditCard do
    defstruct balance: 7_279.0,
              apr: 24.45,
              daily_periodic_rate: nil,
              minimum_percent: 0.02,
              minimum_floor: 27.5,
              last_due: nil

    def new(fields \\ []) do
      fields
      |> Keyword.put_new_lazy(:last_due, &Date.utc_today/0)
      |> then(&struct!(__MODULE__, &1))
      |> then(fn card ->
        %__MODULE__{card | daily_periodic_rate: card.apr / 100 / 365}
      end)
    end

    def payment_schedule(card, overpayment \\ 0) do
      Stream.unfold(card, fn
        %__MODULE__{balance: 0.0} ->
          nil

        card ->
          payment =
            CreditCard.Payment.new(card)
            |> CreditCard.Payment.advance_due_date()
            |> CreditCard.Payment.accrue_interest()
            |> CreditCard.Payment.apply_payment(overpayment)

          {payment, payment.card_after}
      end)
    end
  end

This code above is mostly just a data structure. The defaults you see came from Google:

• Average balance
• Average APR
• Average minimum payment

The CreditCard.payment_schedule/2 function provides a public interface for repeatedly making payments, until the balance reaches zero. A payment involves a few steps, but the keys bits are that interest is accrued for days past and then a payment is applied to the new total. A minimum payment is always made, but we can choose to pass an overpayment amount.

The trickiest line in the code above is probably where I convert the APR to a daily_periodic_rate. Is this using math knowledge? I don't think it has to be, since the formulas needed are easily Googled. (Yes, I've made some simplifying assumptions: assume the full balance is already subject to interest, ignore details like cash advances to assume the whole balance is under the same APR, and assume no new debt will be added.)

Let's look at the payments:

  defmodule CreditCard.Payment do
    defstruct ~w[card_before card_after days interest minimum paid]a

    def new(card), do: %__MODULE__{card_before: card, card_after: card}

    def advance_due_date(payment) do
      # try to jump a month forward
      last_due = payment.card_before.last_due
      next_due = Date.add(last_due, Date.days_in_month(last_due))

      # correct if we overshot a shorter month (not possible in November or
      # December, since both December and January have 31 days)
      next_due =
        if next_due.month == last_due.month + 2 do
          Date.add(next_due, -next_due.day)
        else
          next_due
        end

      days = Date.diff(next_due, last_due)

      %__MODULE__{
        payment
        | card_after: %CreditCard{payment.card_after | last_due: next_due},
          days: days
      }
    end

    def accrue_interest(payment) do
      card = payment.card_after
      interest = card.balance * card.daily_periodic_rate * payment.days
      new_balance = card.balance + interest

      %__MODULE__{
        payment
        | card_after: %CreditCard{payment.card_after | balance: new_balance},
          interest: interest
      }
    end

    def apply_payment(payment, overpayment \\ 0) do
      card = payment.card_after

      minimum =
        card.balance
        |> min(card.minimum_floor)
        |> max(card.balance * card.minimum_percent)

      paid = min(card.balance, minimum + overpayment)
      new_balance = card.balance - paid

      %__MODULE__{
        payment
        | card_after: %CreditCard{payment.card_after | balance: new_balance},
          minimum: minimum,
          paid: paid
      }
    end
  end

Another data structure and three public functions as the interface for manipulating it. The longest function finds the next payment date, because calendaring might be the only subject more complex credit cards. The interest calculation is right out of the formulas page I linked to above. Finally the actual payment function has to sort out whether we're paying the minimum percentage, using the minimum floor, or just paying the full remaining balance, depending on how much is left on the card.

That's enough for us to see how long it'll take to pay off an average debt if we stick to minimum payments:

  payments =
    CreditCard.new()
    |> CreditCard.payment_schedule()
    |> Enum.map(& &1.paid)

  %{
    months: length(payments),
    total_paid: payments |> Enum.sum() |> Float.round(2)
  }
  |> IO.inspect()

%{months: 87414, total_paid: 6257806.8}

Over 7,000 years and $6,000,000? You would be forgiven for assuming that I have a bug! But do I?

Let's examine the first five payments:

  CreditCard.new()
  |> CreditCard.payment_schedule()
  |> Enum.take(5)
  |> IO.inspect()

[
  %CreditCard.Payment{
    days: 31,
    interest: 151.1539191780822,
    card_after: %CreditCard{
      balance: 7281.550840794521,
      apr: 24.45,
      daily_periodic_rate: 6.698630136986302e-4,
      minimum_percent: 0.02,
      minimum_floor: 27.5,
      last_due: ~D[2023-11-16]
    },
    card_before: %CreditCard{
      balance: 7279.0,
      apr: 24.45,
      daily_periodic_rate: 6.698630136986302e-4,
      minimum_percent: 0.02,
      minimum_floor: 27.5,
      last_due: ~D[2023-10-16]
    },
    minimum: 148.60307838356164,
    paid: 148.60307838356164
  },
  %CreditCard.Payment{
    days: 30,
    interest: 146.32924771843236,
    card_after: %CreditCard{
      balance: 7279.322486742694,
      apr: 24.45,
      daily_periodic_rate: 6.698630136986302e-4,
      minimum_percent: 0.02,
      minimum_floor: 27.5,
      last_due: ~D[2023-12-16]
    },
    card_before: %CreditCard{
      balance: 7281.550840794521,
      apr: 24.45,
      daily_periodic_rate: 6.698630136986302e-4,
      minimum_percent: 0.02,
      minimum_floor: 27.5,
      last_due: ~D[2023-11-16]
    },
    minimum: 148.55760177025905,
    paid: 148.55760177025905
  },
  %CreditCard.Payment{
    days: 31,
    interest: 151.1606158582637,
    card_after: %CreditCard{
      balance: 7281.873440548939,
      apr: 24.45,
      daily_periodic_rate: 6.698630136986302e-4,
      minimum_percent: 0.02,
      minimum_floor: 27.5,
      last_due: ~D[2024-01-16]
    },
    card_before: %CreditCard{
      balance: 7279.322486742694,
      apr: 24.45,
      daily_periodic_rate: 6.698630136986302e-4,
      minimum_percent: 0.02,
      minimum_floor: 27.5,
      last_due: ~D[2023-12-16]
    },
    minimum: 148.60966205201916,
    paid: 148.60966205201916
  },
  %CreditCard.Payment{
    days: 31,
    interest: 151.21358833600186,
    card_after: %CreditCard{
      balance: 7284.425288307241,
      apr: 24.45,
      daily_periodic_rate: 6.698630136986302e-4,
      minimum_percent: 0.02,
      minimum_floor: 27.5,
      last_due: ~D[2024-02-16]
    },
    card_before: %CreditCard{
      balance: 7281.873440548939,
      apr: 24.45,
      daily_periodic_rate: 6.698630136986302e-4,
      minimum_percent: 0.02,
      minimum_floor: 27.5,
      last_due: ~D[2024-01-16]
    },
    minimum: 148.6617405776988,
    paid: 148.6617405776988
  },
  %CreditCard.Payment{
    days: 29,
    interest: 141.50744522395203,
    card_after: %CreditCard{
      balance: 7277.41407886057,
      apr: 24.45,
      daily_periodic_rate: 6.698630136986302e-4,
      minimum_percent: 0.02,
      minimum_floor: 27.5,
      last_due: ~D[2024-03-16]
    },
    card_before: %CreditCard{
      balance: 7284.425288307241,
      apr: 24.45,
      daily_periodic_rate: 6.698630136986302e-4,
      minimum_percent: 0.02,
      minimum_floor: 27.5,
      last_due: ~D[2024-02-16]
    },
    minimum: 148.51865467062387,
    paid: 148.51865467062387
  }
]

If you look closely at the first payment, you can see that the interest is a little more than what we're required to pay. Our balance actually went up by a couple of bucks!

The second payment was better, because it happened in a month that's one day shorter. It cost us less interest. After making both payments we're about 32 cents above where we started. So what saves us from a forever climbing balance?

February. Check out that fifth payment. Unfortunately it landed in a leap year, so it still has one more day than normal. However, it's enough of a win to undo the damage of the previous four payments and leave us over a buck and a half to the good.

This cycle repeats for a very long time, with each new February gaining a tiny bit of ground. Eventually we reach a point where all payments are more than the interest and a payoff can be reached. Even that is slow going though.

When you're in this situation, little changes can have a huge impact. Look at the differences we see if we just up the minimum payment percentage to the higher end of average:

  payments =
    CreditCard.new(minimum_percent: 0.03)
    |> CreditCard.payment_schedule()
    |> Enum.map(& &1.paid)

  %{
    months: length(payments),
    total_paid: payments |> Enum.sum() |> Float.round(2)
  }
  |> IO.inspect()

%{months: 258, total_paid: 20606.42}

We're still paying for over 20 years and it'll cost nearly three times the amount charged, but this seems like a miracle compared to the previous outcome.

What if we tossed in an extra $10 per month?

  card = CreditCard.new(minimum_percent: 0.03)

  overpayments =
    card
    |> CreditCard.payment_schedule(10)
    |> Enum.map(& &1.paid)

  overpayments_total = overpayments |> Enum.sum() |> Float.round(2)

  minimums_total =
    card
    |> CreditCard.payment_schedule()
    |> Enum.map(& &1.paid)
    |> Enum.sum()

  %{
    months: length(overpayments),
    total_paid: overpayments_total,
    savings: Float.round(minimums_total - overpayments_total, 2)
  }
  |> IO.inspect()

%{months: 178, total_paid: 17481.32, savings: 3125.1}

That saves us over six years and $3,000 even with the increased outlay of cash each month.

Hopefully you get the idea. I think math holds a lot of value to humans in general, regardless of where we land on the programming issue. Just refreshing algebra and geometry can do a lot for you, if it's been a while. In a world where typical credit card debt turns into a life long reduction of income, this stuff matters!

Let's return to the main question.

Why do some say that programmers require math? I've seen other possibly related claims. One was a job description for a tech savvy position that wanted applicants to have, "completed an Intro to Programming course (HTML doesn't count)." Another was a code school that sought students, "comfortable with the command-line." Who's comfortable with the command-line that's not a programmer? Almost programmers?

Programmers need a pretty diverse set of skills when you really think about it. There's the obvious technical know-how, which can be plenty to get your head around. But that's not even close to enough.

Programmers translate human requirements into machine instructions. Strong communication is vital for tasks like requirements gathering and documentation, at a minimum. Still, there's more.

Rarely does code spring fully formed from a programmer's head. Most solutions need to be discovered. Programmers spend time exploring the domain to gain familiarity and insights. Then there's a stage of modeling where the struggle is to balance human needs with what's viable for computers. This is creative knowledge work that leans heavily on areas like logic and problem solving. Who's typically experienced in logic and problem solving? Math fans, for one.

So where's the disconnect? If we know what's needed, why do we apply all of these specific filters?

I suspect that we have a training problem. A typical Elixirist probably studies:

• The core language
• Specific domains and/or specialized knowledge
• And maybe some general theory

I personally haven't seen many classes on respectful collaboration, logical deduction, or even just abstract thinking. It seems like we need them though. Otherwise, we're only learning half of our job, and I worry it's the easier half.

I'll say it again: I don't think strong math is essential for programmers. However, systemic problem solving definitely is. We need to enhance our study of these areas as a community. Even more importantly, we need to get better as teaching them.