[diminishedprime]

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.

[joezydeco]

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

[tptacek]

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".

[SiVal]

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.

[mjevans]

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.

[facetube]

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.

[_asummers]

0.20000000000000000, 0.20000000000000001, 0.20000000000000002 also work.

[joezydeco]

Hah! Nice catch.

[tptacek]

Pentester. :)

[jrapdx3]

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.

[johnsonjo]

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.

[ubernostrum]

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).

[perlgeek]

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

[bbcbasic]

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

[__david__]

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

[eli]

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.

[Ntrails]

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?

[ubernostrum]

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.

[jonkiddy]

[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.

[jws]

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

[WildUtah]

It accepts floating point numbers. To approximately double precision.

But it accepts zero percent of real numbers.

[eru]

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..

[elnion]

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.

[profinger]

I did this plus also testing [1 1.5 2]

[rahimnathwani]

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