Much appreciated!

Appreciated!

Rust sample tests do not compile. A few test cases do not compare to an Option<usize> as they should, and the case for None expects -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, where abc is 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:

[5789, 7078, 659, -8368, -1095, 360, 5335, 4182, 8784, 3830, 2452, -4398, 4410, 4608, -7401, 3961, -7297, -5611, 7955, 9161, 1562, 1952, 9472, -1753, 5727, -8722, -8811, -9806, -9466, -3573, 6676, 7551, -2884, -7086, 8519, 9270, -2223, -5293, 8054, -4715, 85, -4782, 1494, 831, -2437, -2135, -6001, 3968, 9474, 6190, 7201, -6982, -1150, 469, 1806, 1725, -7172, 5396, 238, -7497, 5832, -1861, -5153, -7039, 2128, 2939, -1313, 3239, -9301, 1996, 5304, -9884, -138, -1445, -6853, 8668, 3299, 1154, -2733, 2285, -3715, 5695, -9500, 3303, -2737, -8601, -5807, -984, 8727, -8406, 7191, 3376, -1435, -2765, -5389, 3566, 3852, 4488, 6611, -4183, 4237, -8503, -4649, 4124, -7322, -1897, 793, -1746, 1349, -4642, 708, -5744, 7057, 7476, 7184, -8886, -6100, -4159, -9482, 1360, 8613, 7757, 5915, -2201, -694, 9151, -54, -6794, 1895, -1122, -4630, 798, -7008, -8878, -9491, -5909, 7831, -9401, 3313, 1427, -8889, 6521, -4197, -8411, -2145, -6102, -2512, -9066, -9214, -8084, 2972, -5576, -5121, -4287, -7635, -4836, 6, 790, -1418, 5979, -922, 7362, -2533, -3569, -4611, 438, -1707, 4295, -2770, -2566, 8889, -4414, -170, 589, -5493, -6894, 2989, 2506, 6505, 1112, -2640, -4028, -3474, -4150, 432, 5009, -5154, 3296, -2099, 6939, -7892, -6705, 2397, -1236, -7946, 8157, -9251, -8327, 4076, 4189, -2035, -2599, 5079, -6689, 4122, -4986, 2211, -6599, -4882, 3159, -6876, 1198, -5061, 6341, 19, 7800, 4074, -3371, -1198, 9149, 9930, -155, 7428, -8635, -8210, -7346, -8099, 4497, -9643, -7382, -9787, 7954, -761, -9015, -9516, -7925, 1910, -843, -72390]

This random test expected an answer of Some(202) which IS a valid answer, but my code returned Some(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)) with dotest(&arr, reference_solution(&arr)) (and probably do a slight refactor to get rid of the extraneous else block). I have a proposed fix here: https://www.codewars.com/kumite/649c7f7f0b00c8003ea81022?sel=649c7f7f0b00c8003ea81022

Fixes 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 an IntStream of an array of ints, and that IntStream.of(a) doesn't support returning an IntStream from 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.

Curse you, floating-point precision!

Well said. You are probably right in that it doesn't need to be stated twice, and I don't think it's NEEDED, but helpful. I kept the author's "left" and "right" rotation and just assumed that they were correct, but it might just be better overall if it's omitted. That would remove my concern of stating the return twice and remove information irrelevant to the problem. Anyways, I am off to sleep for tonight. I think what we have works well if the author looks at this and updates it.

I suppose if I'm going to argue that it is poor that I should offer a better solution. Here's what I propose then:

Write a function that takes as arguments two strings and returns positive (True/true/1) if one string is a rotation of the other or else returns negative (False/false/0).
A pair of strings are rotations of each other if they are the same string OR if you can take the letters from either end and move them (preserving their order) to the opposite end you took them from. Examples:

For example:

// ohell is left rotation of hello, since you can take the 'o' and move it to the front. A single letter can't lose its order.
isRotation("hello","ohell") => true

// elloh is right rotation of hello, since you can take the 'h' and move it to the end. 
isRotation("hello","elloh") => true

// llohe is right rotation of hello, since you can take the 'he' and move it to the end. The order is kept, since the 'h' still comes before the 'e' of the letters that were moved
isRotation("hello","llohe") => true

// elolh is NOT a rotation of hello, since the letters lose their order. The two 'l's in 'hello' will always be next to each other, OR one at both ends of the word.
isRotation("hello","elolh") => false

Keep in mind you only have to return true for rotations and false for non-rotatations (or their equivalent boolean values in your language).

I think that would do better as the kata description. A few more words, but I think they clear things up. Agreed? I'm open to hear what you have to say, you have more experience on this site than me.

Yes, it IS my wrong interpretation Chrono, but my point stands. You want to remove ambiguity. Yes, I'm wrong. My suggestion there was to have it to where less people will be wrong. Miscommunication goes both ways.

Glad I could help.