Thanks for clarification, knowing that I am expected to round only the final results and not the partial results will definitely assist me in debugging. I'll try to handle this myself first, thank you for your assistance!

Rounding method seems ok, if you get differences that high, the problem isn't in the rounding part. Try pasting your code and marking your post as having spoiler content for us to check it.
You should only round the result.

It varies because I have several solutions.

Generally speaking I rounded it with several different methods, and at different levels - i.e. in one test I've only rounded the final result, in other tests I've rounded all the multiplied values, in yet another I've rounded only some of them.

The higher the precision* I've kept, the bigger the gaps were. I've received the "consistently closest values" (i.e. difference of 0.05 not 0.5) by doing the "appropriation" and not even the roudning by using the following imprecise formula: Math.round(value * 1000d) / 1000d;

I've verified some of the results manually and for the method that I've thought should give the highest precision I've had same results as on Google's and Microsoft's calculators. If I am wrong, please hint me the right method of how is rounding done in Java.

*"precision" is pretty relative as I am definitely not an expert it this field

The java version seems correct though. What are the assertion messages you got?

I've tried doing this in Java but I fail on random tests.

I've searched for most precise methods of doing this and avoided common imprecise rounding methods.
I've analysed the values and calculated the areas by hand and I stand with the results my code produces.

Could you please take a look at the Java TC's translation?

Yes, the flip is disturbing, but since the instructions state this clearly, I can handle it. What bothers me even more is that the instructions do not state how x and y are related to columns and rows. All that is stated is that x: 0, y: 0 refers to top-left. It should be stated more clearly in the instructions whether the x refers to the columns (i.e. the sub arrays in the map) or the rows, (the value of each sub array), especially since they redefined how a 2D map is configured with 2D arrays.

A question, not an issue.

Better to use .count('r') once and store in a variable.

Hi, can I ask you something? Do you know what the runtime of your solution is? I'm using two reduce methods (1) to populate an object, (2) to find all instances where the sum of the current value is being matched with the difference of the current value and the sum. And accessing that sum is being matched by the object I have constructed earlier. I believe that my solution is O(2n), I just want to know what yours is because one would think that an acceptable solution would be O(n).

How do you Google for "~" ? :(

Woah, no lambda, I am amazed. I gotta research the ~- thing.

Interesting Kata. I'll come back to it, and I think to CW alltogether, once I'll solve the challanges on project Euler - often I found myself stuck because my approach to given tasks are too brute-force. In the job I do, its not a problem, but in the jobs I'd want to do, it is.
Thanks for the direction.

Surprisingly satisfying Kata.
Also, regarding the random input generators, as of 2nd of July 2017, its pretty specified that you can only use one_two() inside one_two_three()