I wanted to do that but ended up doing an if statement in the Select method... your version is better!

You could also just create a range from 0 to word.Length exclusive and make an array out of any i where word[i] is upper

LINQ ALL THE THINGS

Excellent - drove me to distraction!

I think people used their "own" gcd since there was no need for "Big Integers" which are certainly slower, though there was no need for performance either... Furthermore it's good to have written, maybe only once, a gcd calculation.
I hope other Codewarriors will answer.
You have a good solution with "streams" and "Big Integers", which is very well. Go on!

I've looked through a few of the answers and noticed that most people have used their own implementation to derive the lowest common denominator which ultimately uses a calc to generate the "greatest coomon divisor". I used the BigInteger class for this - which gives you "gcd()" for free. Is there a reason that the previous 174 people haven't used it? Performance maybe?

Would love to know as my Java experience is limited - so am trying to utilise/learn as much as possible.

agh! Finally finished this - my answer works, though verbose.
My only observation is that failng tests require should state as a minimum what the expected value is.

Fantastic learning exercise though.

Make sure that your solution handles whitespace tokens correctly. That's the best I can suggest with the given information.

Am getting

testSingle(SimplexerTest)
expected: but was:

Any help here? I have no idea what condition I am failing. All cases of a single 'token' have been covered?

The following needs explaining:
"If the rounded headwind component is 0, "Head" should be used. Similarly, "right" in case crosswind component is 0."
As a pilot, if I calculate a headwind/tailwind component as zero, I am in a situation where I have a "pure" crosswind (i.e. 90 degrees from left or right.) Similarly a crosswind component of zero can only be directly ahead or behind me. For a reasonable proof check out the calculator at: http://www.aeroplanner.com/calculators/avcalcdrift.cfm

The kata tests need changing to either define more correctly the method to be used, or take the above into consideration.

Nice idea for a problem; poor implementation though. Dissapointed.

Remove the "static" from the test
This too should be fixed

I agree...
It is entirely feasible that the result of squaring the digits in the source exceeds Integer.MAX_VALUE - this should have been a test case.