Loading collection data...
Collections are a way for you to organize kata so that you can create your own training routines. Every collection you create is public and automatically sharable with other warriors. After you have added a few kata to a collection you and others can train on the kata contained within the collection.
Get started now by creating a new collection.
EZ game when using minifiers
awesome
Updated tests in JS and TS:
The number of tests has been reduced; attempted to make the tests more demanding in terms of performance.
approved with fork
Fair! I've modified the description to use markdown instead of html, and added the clarification for Python. Fork is here
I took issue with it, so made it an
issue
:PIf you want to change the description, a fork is sufficient (unless there are pending translations - which there aren't - because this would then cause those to need updating too)
I agree that it should be added to the description, but disagree that it's an
issue
. The difference between the inclusion and exclusion of that is the addition or removal of a single measly "cast" on the user's part. It's not like it will drastically change the user's algorithm thereafter - it's a very universal DP exercise and the core of the methodologies is largely language agnostic. I chose to work with tuples to give Python solvers the same level plane they have in the JS version, where they don't have to care about a particular error flooding their logs, and also to enforce that thewords
array is not to be tampered with. It also helped that dealing with tuples made generating testcases as convenient as it is in the JS version. Words shouldn't change, so making it a tuple is the right semantic call regardless.But it's a very fair point that the user needs a heads up that all args are tuples. Do I fork the Kata with the description modified or wait for someone who can directly edit the Kata (if that's a thing?).
Because this kata (at least in Python) requires as its solution a very specific "technique". Said technique requires the argument types to have a certain property. The method which implements the "perfomance" of the performance tests generates inputs that also lend themselves specifically to employing this technique. Everything revolves around that (otherwise this would literally just be a different version of Elemental Words). Thus, I think that little bit of info belongs in the description, because it's fundamental to the task.
Why not put that sort of info in the solution setup instead?
The description explicitly mentions that the inputs are
arrays
in multiple places, however, in Python, they are alwaystuple
s (as opposed tolist
), which is a crucial detail that would obviate the need for certain preliminary work in the user solution.While it's not a major problem, it is a bit confusing looking at a bunch of top solutions and wondering how the hell they're getting away with what they're doing.
The description could use language specific blocks for these kinds of details since they are relevant to the implementation of the task.
this seems hard
Cool, thank you!
This comment is hidden because it contains spoiler information about the solution
Very readable!
Approved by someone
Loading more items...