Hah :)

Seriously, though, it seems a bit of leap from the existence of confirmation bias to explaining away the public outpourings of US Politicians about their financial crises and foreign policy disasters - in the absence of better data as to just why the given statements were made ascribing this to confirmation bias seems itself open to accusations of confirmation bias! :)

I mean, it also illustrates how training and systematic reasoning can improve these things. Whether explicitly or implicitly, I picked up certain skills and procedures for problem solving (from programming and math contests) that I now use by default. Trying a bunch of examples, coming up with a hypothesis, trying to disprove it, testing edge cases…

This doesn't mean I always use these—at the very least, I have to explicitly jump into "problem solving" mode—but it means they can be useful.

It's still a meaningful difference, and could very well apply to lots of things beyond this kind of puzzle.

That's exactly what I was thinking. I (sometimes) follow TDD, and I applied it to this problem. I made sure to include negatives, 0, positives, and include primes here or there to help avoid issues with multiplication/exponentiation. After a few of these, I felt pretty confident that the rule was simple.

Did you try floating point numbers? I didn't see anything in the text that said integers only.

I tried floating point numbers. Also, at 28 decimal places, the test breaks; it's not arbitrary precision. So, technically, the answer isn't simply "any ascending sequence of numbers".

I actually avoided going that far to avoid getting bad data. I was trying to answer the question, "What does the experimenter THINK his rule is?" rather than what will the computer do. Since the computer can't be infinite, it will inevitably fail with overflow, underflow, and such.

I was relieved, in fact, when it worked with negatives and floats in a "safe" range.

I also tested with 1,1,2 and 1,2,2 to make sure that the required increase applied to ALL of the values, not just a specific pair.

I too tried to test if it was only one pair that was significant. However I grew impatient and didn't try to come up with more tests when I thought I had a sufficient answer to explain my most vexing observation (negative, positive, positive out of combinations involving negative numbers).

The observation to brainstorm for ways of proving that a statement is in fact wrong, and exhausting them, is such an eloquent way of wording the hunt for a negative.

The slightly-shorter 0.60000000000000000, 0.60000000000000001, 0.60000000000000002 will break it too, for what it's worth. If you punch those in to a Javascript console, you can see that the FP representation of all three is 0.6.

0.20000000000000000, 0.20000000000000001, 0.20000000000000002 also work.

Hah! Nice catch.

Pentester. :)

Yes I did, though not to 28 places as tptacek had done. With 2 to 4 place floats, including negatives, the test worked as expected.

Like others here have said it wasn't a particularly hard "rule" to figure out. Easy to immediately rule out geometric relationship as in 2^y, which didn't leave a whole lot of possibilities to test. For the commenters here, I'd attribute ease of finding the solution to familiarity with the kinds of problems that programming presents.

Which leads to the idea there's value in learning even the rudiments of programming. Logically, it should encourage better problem-solving skills in general. We might think there this has important implications for our educational systems. But I know, that's probably not realistic at all.

I know the question isn't directed at me, but I thought you might want to know. I couldn't try negatives or floating point on the iPhone. The keypad didn't have the option.

My process was:

    [3 5 7]
    [7 5 3]
    [8 4 2]
    [5 7 3]
    [1 2 3]
    [1 1 1]
    [0 1 2]

At that point I could've done some more to be really certain, but felt confident enough and guessed (correctly).

So you limited yourself to non-negative integers, and had no idea what negative numbers or fractions would do.

Also he didn't know what numbers whose digits add up to 88 would do.

Their input on the phone wouldn't allow minus or period characters so I assumed positive integers were the set.

Based on the context of the question and the UI of the testing interface, fractions seem unlikely to be an intended part of the question. I likewise wouldn't bother testing unicode U+216x roman numerals.

It refused to accept both fractions and imaginary numbers. I did test negatives and zeros since that was really the only remaining set I could think of.

Most importantly I used about 6 tests (3 right 3 wrong) to come up with the answer and then did another 17 looking for the trick. After all, it couldn't just be that simple right?

The presentation of the problem -- and I know that trusting the problem state is unwise sometimes in cognitive-bias tests, since many such tests are actually designed to be "we said we were asking X but actually meant Y" -- indicated a simple rule, rather than one which would behave differently on different classes of numbers.

So after the tests listed above I felt confident enough to guess.

[16 32 64] [0 0 0] [1 2 3] [3 2 1] [-1 0 1] [3 5 7] [-2 -1 0] [111 54231 9999999999999999999999]

At that point, I correctly answered the question.

Similar to mine, but we both actually failed. Real numbers are accepted and we did not test that.

It accepts floating point numbers. To approximately double precision.

But it accepts zero percent of real numbers.

I can nitpick better than that!

To talk about a certain fraction of real numbers you have to have a distribution over them. In general we take the uniform distribution if no distribution is explicitly given. That doesn't work for real numbers (it doesn't even work for natural numbers). (See https://math.stackexchange.com/questions/14777/why-isnt-ther...)

If there's no implicit default distribution, we have to pick on. I can pick one where they cover an arbitrary high percentage of real numbers..

Down the rabbit hole of pedantry: we don't need a distribution, just a measure, if we want to talk about how many reals it accepts. The Lebesgue measure is implied on the Reals if none is given, and the computable reals have measure zero.

We can't reasonably talk about a percent coverage, since the Lebesgue measure of the reals is infinite, but as a non-technical description, 'zero percent' is morally equivalent to saying it only covers a measure-zero set.

I did this plus also testing [1 1.5 2]

I was a little less systematic, but still had a positive:negative ratio of 1:2 before I submitted my answer.

4,6,8 Y 1,1,1 N 1,2,3 Y 1,6666,8777 Y 1,0,1 N 3,2,1 N 3,2,3 N 5,6,4 N 7,5,6 N

Exactly. I'm just as 'No' averse as the next person but the 'No' I'm averse to is the one where you make wrong assumptions and it comes back to haunt you afterwards.

I was just writing this out! I believe practice in unit testing is what let me get this question right. I almost submitted n^1, n^2, n^3 before I realized I didn't get any wrong answers and something didn't feel right. I credit this 'instinct' to having written thousands of tests, and trying to make them fail to make sure my tests weren't lying to me.

It's funny. Even though I got the right answer, looking back, I still see many holes in my tests. I only tested positive and negative integers. I didn't even think to try fractions, decimals, hex values, text, etc. and I was already expecting a confirmation bias test.

got tricked even if I tested 1, 1, 1

1, 1, 1 was actually the test case that clued me in that n^1, n^2, n^3 couldn't be the right solution.

n=1?

But I totally see why it would cause you to pause and rethink your original idea :).

The point is that it didn't work, so exponentiation was out the window.

My point was that 1,1,1 is 1^1,1^2,1^3 and actually fits the pattern :).

Right - by fitting the pattern but failing the actual criterion, it disproves the consecutive exponents hypothesis.