First of all, relax my guy. Second of all, why are you doing a 6 kyu question when you just started the language? Go to simpler questions and make your way up. Thirdly, it took me a while as well so ur not alone.

Looks much harder than most other 5 kyu task, consider reestimate it.

I get stack on this Ns I don't know why it's returning 5 instead of 10

Error is on Ns

Nevermind, found an edge case I wasn't handling :) disregard!

C#: I have a feeling that there's possibly a broken test case. The test case doesn't show me the contents of the test arrays, but it is Test8. All other tests are passing. I checked the discussion section and noticed a lot of people bringing up broken test cases.

Two things that should have been made clear

1. The numbers might be larger than int (C++) can store
2. When two numbers have same sums of digits, the lexicographically smaller string should come first

Dayuuum, 6kyu??? Feels like 5. It took me 2 days to solve.

Very poorly described, very few test examples, not a great kata at all.

Thank you sir for this kata.

it seemed to work fine on my machine

this is not surprising and that's exactly the problem with undefined behavior in C/C++ ... many things can happen depending on the platform, the way the code is run, the compiler, etc. the worst case scenario is when nothing special happens, until that one day when a cryptic bug pops up from nowhere. there are some tools that can help, such as static analyzers. when i ran your code in this one, it correctly detected UB when run with an empty string (warning, this analyzer is free and online but it's a bit slow and the UB diagnostics can be a bit cryptic if you're not well versed on low-level details)

In Python everything seems to be +1-3 kyu easier, while half as fast.

thanks alot, small change big difference :)

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.