I tried a negative series and a decimal series, just in case the rule was increasing natural numbers. I tried very large numbers to see if there was a limit to the rule, and a series that had large contrast in between each element. For fun I tried to see if the app would recognize "pi", "i", or "e", but, perhaps unsurprisingly, it did not.

I would have checked complex numbers for fun but there is no reasonable ordering of the complex numbers in the way there is for real numbers. It's too bad it didn't recognize pi or e.

I did test with negatives, but I did not think to test with decimals. 15 yes's, 6 no's, and I successfully determined the rule.

I tested with negative integers, but didn't think to test with real numbers unfortunately. (Still got it right, but I should've tested that.)

That said, I did make sure to test all the edge cases I could think of. I was actually going to guess (n^1, n^2, n^3) at first, until it failed for (1, 1, 1).

10 "yes" tests, 6 "no" tests.

I wonder if somebody tested the rule to be deterministic by entering same number over and over. But I think the rule a<b<c is too simple to invite to use creative tests.

Yes and yes. It wouldn't activate the "check" button with complex numbers.

There isn't a way to check order for complex numbers in any reasonable way.

But the problem statement doesn't imply the rule involves ordering.

Likely, it doesn't accept complex numbers (or vectors or matrices) as input as part of the (implicit) spec: in common parlance, "number" tends to mean real number.

The tests with real numbers indicate that the rule is one based on order. So the problem doesn't state this but it is easily deducible when working with real numbers. Hence no need to check complex numbers. In common parlance in mathematical circles "number" tends not to mean real number unless context makes this obvious.

I got it right, using decimals - I was probably a little too exhaustive...

http://imgur.com/6adtvqz

I tested with real numbers to be curious, just tried 1.1, 1.2, and 1.3.