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.
Looking at this kata but haven't tried it yet. That said, the parser would know how many parameters the function needs when it sees its name. Thereby knowing how many expressions to parse to be able give it the parameters it needs. Keeping in mind that an expression would continue to parse as long as it possibly can and still being a valid expression. Thus the parser would parse two subsequent expressions (resolving "2 + 5" and "3" respectively) and give them to the function, evaluate it, and continue on.
It will not stop at just the "2", because "2 + 5" is a valid expression; it will however stop there, because "2 + 5 3" is not a valid expression (as per the grammar).
I hope that makes sense.
issue 6 years old, author incactive, 322 warriors solved it, translated to other 2 languages, I am presuming, based on these fact, that description is ok. I am closing this issue, as it is stopping kata with 88% rate from further progress in beta process. If anyone disagree, please do suggestion or fork with better description.
Much appreciated!
This comment is hidden because it contains spoiler information about the solution
No good reason to change specs and invalidate solutions on an ancient kata.
Appreciated!
I've fixed the Rust translation, sample tests should now correctly use
Optionsin the assertions. A reset of the trainer might be necessary to see the changes if you've already started training on them, however I wouldn't bother since the actual test suite is not affected by this issue.This is very odd, since the approved translation has correct sample tests. Not sure how these (outdated) sample tests show up when entering the trainer. I'll look into it.
Rust sample tests do not compile. A few test cases do not compare to an
Option<usize>as they should, and the case forNoneexpects-1.I would imagine this goes against the original idea of the kata, and additionally, this would invalidate a lot of solutions. It's a major change for a kata years old. This could be incorporated into a separate kata that expands on the idea of a PaginationHelper.
How should the expression
5 + abc 2 + 5 3, whereabcis a function with two parameters, be evaluated?This expression is permissible by the grammar, however the language spec lists
+as a higher priority than functions. Intuitively, I'd want to just evaluate the function first, but that seems to go against what is explicitly stated, unless I'm misunderstanding how priority works.Edit: To anyone else wondering about how the priority properly works, function calls are the highest priority. Then, the operations in the table follow accordingly. Function assignment is the lowest priority.
Not a problem, I'm glad I could help :D
There's an issue with the Rust version of this kata. According to the problem description, "if you are given an array with multiple answers, return the lowest correct index".
This is not true in the Rust translation. Here is an example where it breaks:
This random test expected an answer of
Some(202)which IS a valid answer, but my code returnedSome(199), which is ALSO a valid answer and has the lower index.This happens when the kata tries to generate a random test with a guaranteed answer but doesn't check that its answer is the lowest valid answer, instead just assuming it's the only answer. This is easy to fix -- just replace
dotest(&arr, Some(i))withdotest(&arr, reference_solution(&arr))(and probably do a slight refactor to get rid of the extraneouselseblock). I have a proposed fix here: https://www.codewars.com/kumite/649c7f7f0b00c8003ea81022?sel=649c7f7f0b00c8003ea81022Fixes a bug where the random test will sometimes have the incorrect expected response. The test where it inserts values to create a guaranteed midpoint does not check that it's the earliest midpoint possible.
It seemed to me after a bit of looking at the documentation that
Arrays.stream(a)will return anIntStreamof an array of ints, and thatIntStream.of(a)doesn't support returning anIntStreamfrom an array, but instead a list of parameters that you give it. Unless I'm misunderstanding the ellipsis in the documentation.Arrays.stream(int[] array): https://docs.oracle.com/javase/8/docs/api/java/util/Arrays.html#stream-int:A-IntStream.of(int... values):https://docs.oracle.com/javase/8/docs/api/java/util/stream/IntStream.html#of-int...-Looking at the solution now, I think that I am misunderstanding it. There doesn't seem to be anything there that says it works with an array of ints. My guess is no, it doesn't matter, unless it's something really finicky with how Java compiles.
Loading more items...