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.
Yours was rejected by someone but a variation of it has been approved!
Whatever is needed, should be done, I think. Tests should include:
It is possible to generate such tests deterministically, and it would behoove a translator to implement such. I do not have the time right now, otherwise I'd fork and write one myself, but I'm sure Pearce is up to it.
Edit: Here's a sample algorithm:
For each test:
gen_bool(0.75)
to generate a positive case, otherwise a negative one. The first option lets you choose the exact number of each test, the second one relies on sufficent cases to produce the desired ratio.true but then you'd need two separate cases as opposed to one
I'd do it the other way around: generate
available
, and sample a random subset of those to form a recipe which is guaranteed to add up at least once. You can then play with the numbers for each ingredient.You can get closer to a 50/50 split without much complexity by either one (or both) of these two means:
recipe
towards having a smaller length andavailable
towards having a larger length. Most translations don't use the same process to generate both from what I've seen.available
after generatingrecipe
. This allows you to subsequently specify that, say 50% of the time, you merge all the keys (ingredients) ofrecipe
into whatever you got fromINGREDIENTS.choose_multiple
before collecting to a dictionary. I don't know if this is convenient in Rust, but it was easy to do in C#.So far the chance of not getting a 0 is 4-5%; I think you should at least incorporate the first approach since most translations do it and it helps even the odds a bit.
Done and done. Pass by value makes it easier for the consumer, but by reference is the better api decision, and at this kata level they can handle it.
Ingredient diversity and count have been reduced for random tests. It's still likely to be mostly 0s, but before there was a decent chance they'd all be 0s. A more nuanced approach would be possible, but require complexity beyond what I think is necessary.
clone()
.Should be
const
instead ofstatic
. Variables should beSCREAMING_SNAKE_CASE
.I agree. I believe my solution has the correct behavior, but it's hard to say without proper testing.
There might also be an edge case where it's important to prioritize bloodied enemies, but I couldn't find one.
Rejected because no answer to requests for more than one year. I think this is not approvable as is. It's always possible to create a new fork and make the required changes.
Needs edge case
[1, 1, 2, 2, 4]
. This should expect2
(kill 2 wolves with melee and shoot the farther wolf once, for 2 turns), but every solution, including author solution, expects3
.Well, except one solution, but this solution has incorrect handling, and fails at
[2, 2]
.The fixed tests are too weak: there are at least several solutions with incorrect checking and still passes. There is one hard-coding solution, and one solution that fails at
[2, 2]
.Random tests almost always has an expected value of
max(distances) - 3
.Please fix mispelling in description too. Also update to the latest version.
Pluto approves
Loading more items...