My directions already stated, "Your job is to return the best starting mark in meters, rounded to two decimal places." I don't know of any katas on Codewars that expect you to round earlier in the process of solving the problem. It should be rather obvious that any imprecision resulting from such early rounding could be compounded in the final result. So unless you find an explicit exception to this rule, you should assume that the rounding always occurs at the end.

I don't set the difficulty level of my own kata. That is determined by other people, who apparently didn't find this one sufficiently challenging to rank it higher.

Please don't enter "issues" on kata when the problem lies in your own lack of knowledge, ineffective solution, or failure to read the instructions. It is not appreciated here, as you will note in many of the forums. In this situation, marking your comment as a "question" would have been the appropriate alternative.

In any event, I am glad that you learned something along the way.

Thanks for taking the time to explain this to me. I had know idea that was how Round works, and I needed the refresher on PC float quirks (been on ~20 year hiatus from coding). Considering that a slight subtlety of how things work is involved in solving this kata, perhaps it demands a bit more depth of knowledge than should be put at a kyu 8 ranked kata. So in the spirit of teaching novice coders (since this kata is ranked as kyu 8) something to guide them to better discover this I think could improve this kata. Just something as simple as to include in the directions not to round until the end (and maybe even a mention of the float precision problem to help introduce the new coder to this concept in combination with the exercise). If it was kyu 7-, where more knowledge is expected to solve the given kata, then that is where no guidance would be more fitting in my opinion. Marking this as resolved, but I hope my suggestion is considered... I know it would've helped me to learn this more quickly with less hassle for all.

C# doubles represent IEEE 754 64 bit floating point values (see .NET documentation).

Some values are not representable by double, like 0.33 (which is stored as 0.33000000000000002) or 9.45 (which is stored as 9.4499999999999993).

Math.Round(x, 2) multiplies x by 100, and then determines whether the remaining fractional portion of the value is greater than or equal to 0.5 (see Math.Round documentation).

If you calculate with values that differ slightly from the "real" values those difference might grow. E.g. 1.235 * 4.565 == 5.637775, rounded to two decimal digits is 5.64. But if you round first you get 1.24 * 4.57 == 5.6668, rounded to two decimal digits is 5.67. The difference between the two multiplicants and their rounded counterparts is smaller than 0.01 but the products differ by 0.03.

Generally speaking, use the highest precision available and only round at the end (if you have to).

C#... Found that all must be calculated then the final answer rounded. If any sort of rounding occurs at the wrong place or any calculates are done a common math practice of using sigfigs (a sort of rounding) then the answer will vary by an unimportant amount (as defined by sigfigs). A slight change ammendment to the details I think could improve the clarity of the exercise. State that only the final answer is to be rounded to 2 decimal places, and all other steps in the calculation must retain their exact value till the end. It is strange that the test cases report back that it is expecting a non-rounded number for example this test case's results (this only happens if it is wrong, otherwise it does accept 9.45 OR the displayed "Expected" number of 9.4499999999999993d works also; one of those floating point quirks perhaps?):
Test Results:
Solution.SolutionTest
ExampleTests
Expected: 9.4499999999999993d
But was: 9.4399999999999995d
Completed in 0.023442ms

General advice:

1. Get the parameters of the failed test. AFAIK every programming language here at CodeWars has some way to print something.
2. Get your result.
3. Re-read the kata's description. There are a lot of issues where the user missed something in the description.
4. Check your result manually (if possible). There are quite a few issues where the user's result was just wrong.
5. Check that kata's discourse section if this issue has already been reported.
6. Add a comment.
   • State your programming language and version as shown at the top of the page.
   • State the parameters of the failed test, your result and the expected result (if available).
   • Add your solution code surrounded by a line with just three backticks (```) and mark the comment as "having spoiler content".
   • Label the comment as "Issue".
7. Give the author a few days to respond.

What language are you using to solve it? Some of the problems reported previously have been specific to certain languages, so I'd like to determine whether that is also the case here.

1. Change digital_root(spezial) to return digital_root(spezial). You need to return the value and you are simply calling the function. Once the function has been called, there is no statement to return and retain the value; therefore "undefined" is returned (default value).
2. Make sure you put a variable declaration name next to your variable. In your for loop, put var before the variable i. This doesn't effect this code, but makes the variable global which may affect your coding in the future if you don't include it (I've seen bugs before because of the lack of it).
3. Use markdown to format your code - see here https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#code-and-syntax-highlighting.

I've left the issues open because they haven't been resolved. The author hasn't been on since February, so the author may fix it in due time. It gives you notifications if there is an issue, so the author can look at them when they get back; your comment wasn't marked as an issue so it's less likely that the author may see it also.

thanks for the answer. i'd already seen your reply in another comment but as tests aren't fixed yet i think it's good to relance the issue...

I'm quite confused by your comment. You might be using the coding structure wrong? You don't have to implement testcases since the Kata already has inbuilt testcases.

Mind if you post your code to this reply so I can see what's happening?

You're meant to return the final output, not print it to the console. Returning the value allow the yields the value, meaning the function call retains this value. The output can be checked for equality using testcases.

Read the comments next time.

In the Java testcases, the expected and the actual are swapped around, so your solution is returning 0 and the expected answer is 7.

Proven by the testcase

assertEquals( "Nope!" , DRoot.digital_root(16), 7);

I get this result in the Python version as well.