It is stated that the function is monotonic. Not that it is monotonic in a given range, but monatomic. The inverse of the given test case in which f(x) = x^2 and f-1(x) = sqrt(x), has 2 possible outputs for every input. It is suggested through the means of only a vague comment above the test case that we should only consider positive values of x for this test. There are no guidelines that we may use, however, for programming for the unexpected cases. Being told in a very specific case a certain range to consider does not give us the ability to generalize the process for determining which value to pick in cases that are not considered before the execution of the program. A program that cannot handle inputs that it was not explicitly programmed for has no purpose. Either the functions that are tested need to be monotonic over their entire domain (I personally think this is the way to go) or guidelines need to be established for how to deal with functions that are monotonic over only part of their domain. The problem is not that certain approaches do not work, but that the problem definition is ambiguous.

I realize that not much activity has occurred on this kata recently, but it is a very interesting challenge that I hope will be fixed. I find the kata that deal with curried functions very interesting and fun to solve.

I ended up writing code to search for estimate bounds, which may not have been the intended approach. Overall, it's an interesting kata. I don't come across very many Numerical Methods kata.

Tiriana, there appears to be a hint in the kata tags.

Any hint on how to implement this in twin? I can't find a way to watch orginal object for new properties nor implement PHP like __call __get methods in twin...

Whole point of writing code using high level languages is to improve readability. Abstraction helps humans.
While it may be fun to try and do everything with one-liners, some people are here to learn and share. When the top solution is too convoluted, people have a much harder time learning and sharing.

@wthit56: In this case, regex is the way to go, since you're going to need regexes for each of the conditions anyway, and putting them into one regex doesn't add to the complexity at all. You could go with 4 different regexes (optionally a length check), if you wanted, and 'chain' the result of each test with &&, but that's pretty much the same thing as doing it in one regex, only slower. Using a singular regex is less readable, though, I'll give you that.

As a bonus, though, you can use pretty much the same regex in html5 form validation* and in your server-side validation.

^*    <input pattern="...">

Is this fixed now?

Raaaagh! Fixed, thank you.

Thanks for pointing that out! Messaging now updated.

If this is fixed, want to check as ready? Pretty sure my other minor issue is that the tests aren't descriptive enough.

Fixed. Thanks for the feedback.

Fixed, thaks.

Ah-- sorry. Typo.

Looks great!