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.
Check what happens when you try to round following numbers: 2.5, 3.5, 4.5, 5.5.
I'm sorry I don't understand what you are both saying, about nearing to the "nearest even integer" (it's probably because of my lack of mathematical knowledge).
In Python, as far as I know, if you try to round let's say
4.6
, it will give you 5, which is the "nearest integer" (not even), just like it's specified in the statement.What am I missing?
Well, exactly this is the case when &Vec<Vec<>> is better. I've started with
but then decided not to overcomplicate the code. We have a matrix type here, represented with Vec<Vec<>>, not an arbitrary slice of Vecs.
Also, there's nothing wrong with negatives in matrix, they should be allowed, but I don't see any actual reason to test them.
Added better diagnostic messages.
Fixed the incorrect function definition in solution setup.
this is now untrue, isomorphism is available :) https://www.codewars.com/kata/isomorphism
Should be marked as resolved
fixed
Yeah, I wanted to avoid overflow, but that didn't work. Thanks for catching that.
I've tried your suggestion, but
b
ended up as0
or1
in most cases.I've also added assertion messages.
Fix
Thank you for reviewing that.
Approved
This comment is hidden because it contains spoiler information about the solution
true but then you'd need two separate cases as opposed to one
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.
Would this be an okay asserion message?
Left - actual result, right - expected result. Test failed on string: "{case_str}"
Loading more items...