Agree, requirements are not 100% clear especially when reading some of the comments here. I actually just finished this kata and based on the test results, it's definitely the case that only order of operations is considered, not parentheses. For example:

t & f ^ t
(t & f) ^ t

Assuming & has equal or higher precedence than ^, the two expressions above have the same exact order of operations, and so should only be counted once.

Ignore the case that does not have inner parenthesis

Why?

What are the rules for how parenthesis are placed?
I think many poeple will skip this Kata because the rules seem unclear, and solving will require guessing and checking against the test cases to understand the problem.

EDIT:
"(t ^ f & t)" is the same as "((t ^ f) & t)"
If each expression is re-written in a notation without parenthesis (using order of operations), the expressions are identical, and count as one.

KenKamau is intentionally being vague about the rules.

CS updated. I didn't touch the random part, but, increasing the number of tests, it seems all is still fine, so...

Reset seems to be working fine in Python. I'm not sure about updating the description? The second item under Invalid handicap usage states that you can't place handicap stones down after they have already been placed (I understand if you didn't see it ;p).

Thanks for updating the coffeescript translation! Does the random testing for it need updating? It should very similar to the JS version in terms of functionality.

mmmm... that's weird. In python, your code has to throw an error for the second call, so the number of handicap stones doesn't matter. You do it in JS, right?

EDIT: java up to date. I raised the number of random tests from 125 to 400, considering the python version is far more demanding.

EDIT²: I tried to update the coffeescript version. No problem for the fixed part, then I looked at the random tests... :/ I saw weird things in there... That made me look closer to your python version (random part): are you sure that your reset method is correct? Seems it's rolling back one step instead of actually resetting the game.

Warning, you forgot to change the error message (python at least):

 Placing handicap stones twice in a row is not valid
   Expected an error thrown with too many handicap stones
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

And you forgot to update the description about that, it seems (couldn't find it, I mean (the description has become quite long, after my completion of the kata! x) )

Python/JS updated! (CoffeeScript is invalid with new tests ;--;)

Desc does say A player cannot place down handicap stones after the first move has been made or handicap stones have already been placed. Throw an error if this happens... Meh, I'm going to go ahead and add a couple tests. One with two handicap calls in a row (error) and the other with a reset in between handicap calls (ok). Thanks for pointing this out, ba78.

mmm right. You sure about not wanting to implement those? My current solution couldn't make several valid calls, for example (it's not resetting the board at the beginning of the method / I believe that most solutions would fail, actually. Thus that may be a bad idea, now?). As you want.

Calling handicapStones multiple times without reseting the board in between should raise an error imo. I don't see value in adding a test for it though.

mmmh, that point could be subject to discussion: if the calls are correct that could match a situation where the players decide to change the handicap before beginning the game. So I'd rather think it's correct to not test that (unless you talked about being sure that it doesn't fail to do so?)

@ba78, Should not expect sample tests to cover everything. That's why they are called "sample" tests.

I think at the level of proficiency required for this kata that the ability to write testing and debugging mechanisms for heap and control flow instructions is reasonable, though feel free to disagree. By not providing those tests in the example suite, and more specifically the omission of edge case tests, it provides the additional challenge to be able to recognize edge cases and write tests to cover them.

There are tests for that. Maybe you missed them by passing them with flying colors?

Ignore the case that does not have inner parenthesis