Fork here.

• Adds fixed and random tests for n=0 (addresses this suggestion),
• Fixes author's solution to handle n=0.

I am not exactly sure what kata you mean exactly, but I remember some kata about Mancala\Sungka\Kalah\Bantumi: Sungka, Pot-tentially the Greatest Mancala Kata. As far as I know, all of them are distinct games, all coming from the common family of Mancala games.

Having said that, I do not know how existing kata, and the games themselves, are close to each other, and whether they are close enough to be considered dupes/repetitive. It's possible, I just haven;t solved the kata.

It is because by use of float and real division operator /, you introduce small inaccuracies into your solution, which sometimes, in certain circumstances, for some inputs, can trick your solution into doing some incorrect approximation, or unintended rounding, because this is how floats work. When you change line 6 of your solution to something like time_decimal_secs = g * 60 * 60 // relative_speed, you have no floats anymore, no inaccuracies, and (if I see correctly) solution with this change will always pass.

You can check what exactly happens by recreating one of failing inputs in your IDE and running it with a step-through debugger, observing intermediate variables. You will notice how in some point, some rounding happens, which slightly changes the outcome and leads to an incorrect answer.

• This kata needs:
  • random tests,
  • inputs presented in failure messages.
• Testing "0 0 0" ten times is not necessary. Once should be enough.
• Comments in the code should be written in English. I would not expect users performing review of tests to be able to read cyrillic letters.
• Potential duplicate of Solving Quadratics

https://www.codewars.com/kata/reviews/68526d48404799a753fa23c9/groups/68528d3184ac1bcf1e0dd799

It's not about tests which are "rounded up". It's about your code which is a bit buggy, and sometimes performs incorrect rounding.

If copilot ever generated me code which contains 96, I would disable it immediately :D

Suggestions:

• Change return type of add to int Function(int) add(int n){ ... } and solution setup to something like:

/* insert return type */ add(int n){
  return;
}

I think that this looks much nicer in strongly typed languages. If someone will solve it with dynamic then fine, but static types are so much neater :)

• Perform two assertions, where first one checks what is returned by add(x). Users who do not know how to do "functions in functions" will attempt to return strange things from add, and tests will crash attempting to call an uncallable thing, resulting in confusing failure messages. You can try something like expect(add(x), isA<int Function(int)>(), reason: "\nadd(x) should return a function");, maybe extracted to a helper function like following pseudocode:

function dotest(a, b, expected) {
  wrapper = add(a);
  expect(wrapper, isFunction<int->int>);
  actual = wrapper(b);
  expect(actual, equal(expectd));
}

(make sure to use reason: for clear failure messages).

Updates tests to Node 18.

Updates tests to Node 18.

Updates tests to Node 18.

Updates tests to Node 18.

Updates tests to Node 18.

I was thinking about using 3-tuple for the return type, which is always a value with three integers. What do you think?