As I was writing the simulation I realized my error. I finished the simulation anyway, just because, and it has the expected 80% result on both of them.

My error: when we trust "both" we're also trusting Alice, which means that my case was exactly the same as just trusting Alice.

PS as I was writing the simulation I did a small sanity test of 9 rolls: I rolled heads 9 times in a row (so I tried it again with 100 million and it was a ~50-50 split). There goes my chance of winning the lottery!

    import random

    def lying_flippers(num_flips=1_000_000):
        """

        - Bob flips a coin and tells Alice the result but lies 20% of the
          time.
        - Alice tells me Bob's result but also lies 20% of the time.
        - If I trust Bob, I know I'll be correct 80% of the time.
        - If I trust Alice, how often will I be correct (assuming I don't
          know Bob's result)?

        """

        # Invert flip 20% of the time.
        def maybe_flip_flip(flip: bool):
            if random.random() < 0.2:
                return not flip
            return flip

        def sum_correct(actual, altered):
            return sum(1 if a == b else 0 for (b, a) in zip(actual, altered))

        half_num_flips = num_flips // 2
        twenty_percent = int(num_flips * 0.2)

        actual_flips = [random.choice((True, False)) for _ in range(num_flips)]
        num_heads = sum(actual_flips)
        num_tails = num_flips - num_heads
        print(f"Heads = {num_heads} Tails = {num_tails}")

        bob_flips = [maybe_flip_flip(flip) for flip in actual_flips]
        alice_flips = [maybe_flip_flip(flip) for flip in bob_flips]

        bob_num_correct = sum_correct(actual_flips, bob_flips)
        bob_percent_correct = bob_num_correct / num_flips

        alice_num_correct = sum_correct(actual_flips, alice_flips)
        alice_percent_correct = alice_num_correct / num_flips

        # Trusting Bob should lead to being correct ~80% of the time.
        # This is just a verification of the model since we already know the answer.
        print(f"Trust Bob -> {bob_percent_correct:.1%}")

        # Trusting Alice should lead to being correct ?% of the time.
        # This model produces 68%.
        print(f"Trust Alice -> {alice_percent_correct:.1%}")

        print()

In a perfect world they drift less than a minute per day and you’re relatively close to the time with an average or just by picking one and knowing that you don’t have massive time skew.

I believe this saying was first made about compasses which also had mechanical failures. Having three lets you know which one failed. The same goes for mechanical watches, which can fail in inconsistent ways, slow one day and fast the next is problematic the same goes for a compass that is wildly off, how do you know which one of the two is off?

You wouldn't be well served by averaging a measurement with a 1% error and a measurement with a 90% error, but you will have still have less than or equal to 90% error in the result.

If the errors are correlated, you could end up with a 1% error still. The degenerate case of this is averaging a measurement with itself. This is something clocks are especially prone to; if you do not inertially isolate them, they will sync up [1]. But that still doesn't result in a greater error.

You could introduce more error if you encountered precision issues. Eg, you used `(A+B)/2` instead of `A/2 + B/2`; because floating point has less precision for higher numbers, the former will introduce more rounding error. But that's not a function of the clocks, that's a numerics bug. (And this is normally encountered when averaging many measurements rather than two.)

There are different ways to define error but this is true whether you consider it to be MSE or variance.

[1] https://www.youtube.com/watch?v=T58lGKREubo

The result in the original article only applies when there are discrete choices. For stuff you can actually average, more is always better.

Oh, and even with discrete choices (like heads vs tails), if you had to give a distribution and not just a single highest likelihood outcome, and we'd judge you by the cross-entry, then going from one to two is an improvement. And going from odd n to the next even n is an improvement in general in this setting.

Or bring only two, but step on one immediately, to get rid of the cursed pair situation, and also to get the clumsiness out of the way early. Old sailor's trick.

Time critical scenarios are one possibility.

In a safety critical scenario intermittent sensor failure might be possible but keep in mind that consistent failure is too.

A jury scenario is presumably one of consistent failure. There's no reason to expect that an intentional liar would change his answer upon being asked again.

Basically what you're doing is breaking down p(correct) = p(correct & agree) + p(correct & disagree) where former is 0.8*0.8 and latter is 0.8*0.2. Explicitly computing the conditional probability however makes calculating more difficult: p(correct | agree)*p(agree) + p(correct | disagree)*p(disagree). This is something like (16/17) * (0.8*0.8 + 0.2*0.2) + 0.5 * (0.8*0.2*2) which is not easy to arrive at intuitively unless you grind through the calculation.

So _conditioned_ on them agreeing you are right ~94% while conditioned on them disagreeing it's a coin-toss (because when they disagree exactly one is right, and it's equally likely to be alice or bob). Interesting case where the unconditional probability is actually more intuitive and easier than the conditional.