@dfhwze Thanks for sharing thoughts and reply/contribute to the thread. I'm thinking that what you suggested can be just a RAG app/component to get the job done, though it's still costly I think. Thinking of another cheaper solution IMHO can be to internally categorize katas by common known patterns. i.e PrefixSum, TwoPointers, SlidingWindowFixedSize, SlidingWindowVariableSize, Search, Sort, Merge, etc. Categories can contain sub-categories like Search can contain (BinarySearch, ExponentialSearch, FibonacciSearch, InterpolationSearch, JumpSearch, LinearSearch, TernarySearch, QuickSelectSearch) where sub-categories are attached by reviewers of katas during Beta period, then the system can report for authors whether the proposed kata is found within the provided category including its sub-categories.

Hopefully that makes some sense, I just find it doable, applicable, faster, cheaper, etc considering the trade-offs and the fault/error margin.

Best,

We should not enforce kata name standards, that would kill creativity. Instead, I believe a better option is to include a search AI assistant in the platform, one that can delve into descriptions of kata's and finds similar kata's for you. Not sure what the cost would be to implement such a feature though.

Please also note that there's provided Go Translation for this mentioned kata that's 3 years ago and still pending!
And there's no way "Or at least I do not know a way, yet" for me to catch a hidden similar kata like this using the search criteria provided prior to consuming time trying to present a similar one with some diffs. I'd rather have spent the time providing something really new and different or missing here on the platform. This "limited ability to find similar katas before authoring" happens because there's no standardized rules or protocol to force kata names/titles to represent something or maybe the search is for titles only not description or somethiing else I dunno tbh.

But I really spend a time searching to avoid duplication & rework before starting to author this. Now turns out that something a bit similar is available but thankfully not equivalent though :(

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,

Thanks 👍 Approved.

C# fork which upgrades the framework testing version to 12.0 (NUnit 4).

I confess it took me a while to figure out how to solve it. good kata.

changed

Code golf restriction: maximum solution length of 38 characters.

limit = 38

# ...

test.expect(size < limit, f'Solution too large')

Your dynamic solution is no longer working.

You are correct, i changed it Thanks

1. https://www.codewars.com/kata/reviews/673c9338222dde58f86b50f8/groups/673c991f9f511a10bbc090bb

2. The code length must not exceed 30 characters.

   Maybe you mean, must not reach 30?

Yes :)