-0.9999 => -0.99
0.009 => 0

With 3 significant digits, this is wrong.
Leading zero in a decimal number is NOT a significant figure.
There is no requirement on the number of decimals after the decimal separator.

-0.9999 => -0.999
0.009 => 0.009

Maybe you should also add a batch of random tests with numbers just below powers of 1000, like 999, 999 998, 999 999 999, and so on ..

FYI, I have yet to pass the kata so there might be more issues with descriptions. But, in general, it is a pain in the *** to read and decipher information. And surprisingly no one raised an issue about this during the beta stage as the whole structuring was lacking some senses...

• Until the deck is empty should be replaced with smtg like while the deck is not empty, do the following operations: ...

• Choose the card index = random number mod deck length. (This sentence is not explained clearly as one may easily consider deck length as 52 instead of the deck where last cards are removed one by one)

• If it's not the last card of the deck, swap it with the last one. (agn, giving mis-information on last card swapping with itself..., should be changed to ..., swap it with the card at corresponding index of the deck.

• Remove this card from the deck and deal it. (deal --> how?)

• For example, we will consider the deal number #1. (Giving users a false indication that it is example 1 or all initial states should start with 1)

• We modify PRNG state again: state = (2745024 * 214013 + 2531011) mod 2^31 = 587473352323 mod 2^31 = 1210316419 (Extra `mod 2^31 in first calculation)

• In some places, you use 65536 while some 2^16, unify it

• Calculate (18467 mod 51) = 5. (should also explicitly mention that the last element was removed, so it's 51 instead of 52)

• Get from deck the card with index 5 which is 2D. --> Obtain card at index 5 of the deck which is 2D.

• Instead of giving 10 numbers starting with seed 1, why not just give all 52 numbers to ease solvers' debugging tasks???

Rust translation ready for review.

Could it be pointed in the task you are going to play yourself? As now it causes some dissatisfaction to return and write its behaviour in losing positions after failure of playing with yourself.

Note: this Kata requires some cheating to solve.

It is really, really, strongly discouraged to encourage "cheating" in kata. This causes many problems with moderation, because users submit full-blown cheats and later rebutt any moderation actions with "BUT I THE KATA WANTS ME TO BREAK RULES!"

I have not solved the kata, but I would kindly ask you to not publish kata which rely on things which are recognized as bannable, or otherwise punishable, cheats (which is, more or less, manipulation of testing framework and essential parts of runtime environment to bypass tests and have no test code run against user solution).

If the kata can be solved with means allowed by the rules, please state explicitly that solution is expected to stay in allowed bounds, and must not manipulate things which it should not. If there is any note in description, it should explicitly discourage breaking the rules of Codewars solutions, and not encourage it.

Scala translation

Clojure translation kumited! please accept :D ( it was hard to do :( )

For java the feedback on the test is flipped. When you return 6 it prints:

expected:<6> but was:<8>

I feel sorry for asking but I really can't get my head around this one.
And even dumber as it is apparently an easy one...
I thought about multiple approaches:

• starting and playing always the same nb in order to "guess" the result
• trying to end up in the skipping position for me
  My feeling is that I should always start as that allows me to predict the opponent play except in case of really low start cakes amount.
  I feel that the key lies of course in the last steps of the game, could I have some hints pls?
  Apologies if I gave too much information

My solution passes every test case, repeatedly. When I submit, the gameplay shows that I win. However, the "easy test" says I ate the last cookie. Mathmatically the gameplay shows otherwise. Disparity between test case and submit test?