And thank you for the kind words about katas! Will try to create some more, though it is more and more difficult to find fresh ideas :-) Cheers

This description is quite generic, and there are exceptions to it. Overall kyu rank is simply about the complexity of the task: simple tasks are white, medium - yellow, complex - blue, very complex - purple.

For example, you may not need to implement a complex algorithm on Brainfuck, but still, the task can be very complex and be of blue/purple rank. Simple Fizz Buzz problem has here a rank of 3 kyu! But according to your logic, it should be 7-8 kyu because there are no "... Computer science concepts using complex algorithms ..."

SQL should also be counted as an exception because it is indeed data manipulation/query language that is not designed as a tool to allow the implementation of complex algorithms. BUT this data manipulation can be of different complexity: simple, medium, complex and very complex; and I think that it is fair that when data manipulation is complex (for example, the necessity to use a lot of window functions in a tricky way), even without the usage of PL/pgSQL, the task deserves to have a blue rank. And when it is very complex, the kata can even be purple, and I recently approved the first purple (2 kyu) SQL kata here, and I don't have doubts that it deserves its rank though it can even be implemented on pure SQL, without usage of PL/pgSQL.

btw, just want to ask in general, why are you estimating my katas so harshly? Like I haven't seen a single kata which you have estimated even as 6 kyu. - even Voile and Unnamed generally estimate more mildly, and they are really tough guys :)

tnx, fixed

thanks for the feedback! made a mistake in my query. Now everything should be ok

Looking at your examples, I would say you might be assigning 1 to a and 0 to b since these are the first elements 'visible' to the assignment operator. In that case, the first thing I would look at is that your ternary operator isn't really working properly in conjunction with the assignment operator.

Try running:

a <- 0 ? 1 : 2
print(a)
b <- (0 ? 1 : 2)
print(b)

If you find:

[1] 0
[2] 2

It's because the parentheses have forced evaluation of the ternary for b

For Rust, the question should simply tell you that the input is guaranteed to be ascii. A harder version could include multibyte characters.

that's out of specs. Moreover, it's 7kyu. Unicodes, accents or anything that isn't basic string char handling shouldn't be added here.

Nope, that does not constitute towards a "word" and if Rust is changed that way, other languages would have to be done the same

Thanks, I'd been wondering about that but never thought to just ask.

Large interval tests are added to all languages.

Fixed

I'm sorry, I don't understand why this is happening. The generator has been fixed. I can publish a new fork (but there will be no difference with the currenc tests), someone needs to approve it first: https://www.codewars.com/kumite/627ffdc0a2670b003d770406?sel=6282288017c6bf8c839675dd

Fixed, thanks.

Thank you for awesome explanation!