agreed, call it "Rubik's Cube simulator" maybe?

oh my bad, give me a second to fix it

done.

Approved. 7kyu average rank

It's O(n^3) vs O(n^2) - that was the point of the problem from my point of view. Anyway, I really regret creating the performance version. I would much rather have had the easier version.

I have added this note, If the number of cookies is < number of elves, return None.

The note takes care of the concern you raised.

Yes, and I'm guessing the mods want to limit this kind of thing in the future.

Doesn't this occur whenever there are two versions of a problem, one requiring an algorithm that can cope with larger values of some input parameter?

I don't think it's a problem that a solution for the harder problem also works on the easier one.

Because people will solve the easy version with a less efficient algorithm, gain access to the solutions page, and then see the solutions of people who solved the easy version with the more efficient algorithm. Then, they can steal that solution and go solve the hard version. It ends up creating more work for the mods to deal with.

I unpublished this one and removed "Performance Version" from the name of the other one. I had to add a space to that name to distinguish it from this one.

It's a shame that this version is gone. Most codewars users will not solve the other one, because they are not aware of OEIS. But many of them had a chance at this one.

I'm very confused - why is it a problem if the solution for a harder version of a problem also works for an easier version? That's always the case for performance kata. If you solve the harder one first, you get the easy one for free.

On your second point, my difficulty level was based on typical dynamic programming problems, like knapsack, subsequence sum, counting change combinations, which are 5 or 4 kyu. But anyway, if reviewers think a kata is good but think it's easier than the author rated it, shouldn't they just indicate what they think the rating should be? Isn't that the whole point of the review phase?

I don't think it's a problem that a solution for the harder problem also works on the easier one. The reason why I made the easier one is for the programmers who are not aware of OEIS (probably the vast majority), and so I was only expecting a O(n^3) solution. This forces a low limit on n, which I'm assuming is the reason for the low ratings. I don't mind withdrawing this version, but my question is whether it's possible to have a codewars kata with a O(n^3) solution.

Ops, Now I get what you mean. Actually I thought at beginning that achieving this in a real world scenario would absolutely be treated differently for production-graded apps like let say using some external libs that might not be doable here in this context. Such libs could be the go-money package for instance "in the context of the language provided initially for this kata". Then I realized that the solution is so far meant to be more general purpose rather than to be more domain-specific or industry bound. Thus mentioned some real-world example use-cases & applications like game development & data science/engineering. Therefore, decided to give the focus on the algorithm aspect of achieving the desired processing time complexity with memory constraint and then the vendor can tailor it to be adapted for all applicable domains.

I'm relatively new to codewars world. Know about it since about 10 years but started to actually use it recently. Since started to delve into it I've seen almost all katas are designed similarly when it comes to this point of percision. I then developed an assumption that people do this on-purpose to intentionally keep it a training/practicing environment as opposed to be that strict. Like a sandbox practice area .. BUT YOU'RE RIGHT. Looks like I misunderstood the point or simply neglected the importance of validating my self-assumptions for the sake of being optimal against sub-optimal!

Please note it's estimated for juniors who look for upskilling & mid-levels to practice/exercise. Of course without sacrificing the correctness, but the performance tagging/aspect here is to force the way of thinking to handle large datasets in minimal time. Additionaly, I wanted my kata to somehow gain some popularity by not being targeted for savvy masters who can figure out what went wrong. Targeted audience here, especially juniors seeking upskilling, might leave it out after struggling/suffering for sometime with accuracy which may causes them to loose focus on the most important aspect of the challenge.

It seems I got lost into details of designing the challenge to the extent that I forgot about or overlooked some other basic approaches that can defenitely be utilized/adopted here for taking care of such percision issues. Though, I just wanted to to keep it focused on the meaty part of the algorithm/problem, or so i think..

BTW, speaking of "strange requirement" I meant my own requirement as i thought my requirement to convert rounded floats to strings is considered a bit strange. I thought the complaint was about string conversion instead of the percision thing. Because what @dfhwze has provided as example of that topic is a bit different from what I expected to be the issue in case I apply that percision precaution. As when I do apply the Fixed-Point Arithmetic I get the following:

Expected
    <[]string | len:5, cap:5>: ["0.69", "3.39", "6.90", "3.79", "10.00"]
to equal
    <[]string | len:5, cap:5>: ["0.70", "3.40", "6.90", "3.80", "10.00"]

While the provided sample says that only the first item is not a match and the rest of the array matches!

Now, I can think of a few paths to take:

1. Apply the percision errors prevention making it deterministic for unexpected issues of rounding & precision, either by following Fixed-Point Arithmetic approach multiplying then dividing to keep values precise. Or maybe using some language features like math/big STD packages. "This will break currently submitted solutions already"
2. Keep it simple & stupid as-is for demo of the basic functionality?
3. Just update the description to highlight such a point and state that its meant to be general purpose then the vendor might like to adapt it for industry domain respectively? This aspect means keep all tests as-is as well, but just to care for proficients & masters playing around to not fall down the rabbit hole once again with poorly designed kata like this 😅.
4. Other?

Kindly advise, Highly appreciate your guidance!

Please note that the currently submitted solution and test cases round the floating decimals after obtaining the final arithmitic calculation of the final sum though. Maybe you'd like to add something here for me to clarify.

I believe designing coding challenges is challenging and is never meant to be straightforward as it must account for all segments and aspects comprehensively.

Cheers,

If a "financial application" builds "financial software" in a way which uses floats to handle monetary values and does not take any precautions to harden it against issues related to rounding and precision, there is no way they can be saved.

It's not "strange requirement", it's straight up a critical error which discards any usability of the software for finacial purposes. And amount of software engineers who try to dismiss this problem is too damn high.