Wanted to convey a msg to author/contributors and/or reviewers tbh

But I never meant that

Okay, i think it must be crystal clear that after every mistake Alex has to redo the failed kata solution .. Thus, consumes more 6 minutes for next trial! Hence, only after successful submission of each kata we can mark it solved and subtract calculated time for this particular kata from the total time provided!
Shouldn't the description be that clear?

Guys, the kata is marked as FUNDAMENTALS and Ranked as 7 KYU. Isn't it?

Being tricky by hiding important info for solving the challenge is different from making the challenge more complex by racking up complexity & difficulty like utilizing different data-structures and/or algorithms for the sake of solving the problem and being really trained on PROGRAMMING.

Brevity is different from conciseness.

Maybe it can be a fit for PUZZLES. But IMHO making the description clear is the way to go!
Think of it as a task handed/provided to you in a day-to-day job/work on a task management tool like Jira for instance, would you like to get your tasks described that way?
People are here to practice programming I swear, Ain't they?!
At least this is the fundamental and principal and main and master and ultimate goal. Then, whoever wants puzzling should visit the relevant space/tag/criteria on-purpose and expect this kind of tricks and be on their own, shouldn't they?

Please review this and LMK your thoughts =)

Kind Regards,

BTW, the kata is great. Fun, well-designed, well-solved, and well tested. I liked it so much! Just like it to be perfect and help future folks avoid questioning themselves and think that tests are written in a wrong manner or mistakenly!

Perfecto =)
Keep Going & Rolling, Gopher!

Tricky one as usual, but really good one!

😂

I've translated it a week a go, but not yet approved. Dunno if that's helpful :)

Kindly LMK your feedbck and whether any help could be needed!

Cheers,

Kindly LMK your feedbck and whether any help could be needed!

Cheers,

@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,

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,

If it's an issue or causing some logical problems I'll be happy to review and discuss further to re-tune & refine. If it's a matter of personal preference I'd also love to learn more from you about your POV and opinion though.

Cheers,

Well well, thanks for your feedback. Appreciate sharing your thoughts :)

You know what, I do believe your point is valid "totally valid". And it came to my mind while working on it .. However, I thought let's do this. Since it can be a requirement that is provided to us as developers/engineers which we gotta follow even if it's not comfortable or even logical "to us" sometimes due to user experience purposes you know! Sometimes clients do ask for some strange requirements for a valid reason that's obvious to them. Hence, I wanted to keep it as an extra trick "maybe not for other languages or trainees" that might spice it up a bit :D

what do you think?

BTW I like your way of thinking, it feels like you love to focus on the meaty part or the backbone of things to craft it up to get things to work and maybe you're not a big fan of nuances that might not be that important as per your respectful perspective?!