Kata

Is this going to be fixed anytime soon?

I would even mark this as an issue; asking for rank without explaining what is asked.

It seems like the testing sequence should prioritize testing with small random arrays first, giving users a better opportunity for debugging.

Test Results:

tests::big_random_arrays

tests::fixed_tests

tests::huge_random_arrays

tests::medium_random_arrays

tests::small_random_arrays

Unlike Python and other interpreted languages, tests are executed in parallel in Rust (and several other languages). I have no possibility to change this and force a particular order of execution (well, strictly technically speaking I believe it is somehow feasible but it's advanced stuff I currently don't dominate, and AFAIK it is not done in any kata).

Also, the way tests are designed doesn't make it hard to focus on small inputs for debugging, it's ok to fold / unfold any part one is interested in. For example (unfolding only fixed tests and small arrays, with a function just returning an empty vector vec![]):

tests::big_random_arrays
tests::fixed_tests
With lst = [1, 3, 3, 9, 8]
Expected [0.0, 1.5, 1.5, 4.0, 3.0]
Got [] at src/lib.rs:26:9
tests::huge_random_arrays
tests::medium_random_arrays
tests::small_random_arrays
With lst = [43, 30, 15, 48, 38, 8, 49, 17, 28, 16, 9, 17, 40, 13, 0, 5, 47, 28]
Expected [14.0, 11.0, 5.0, 16.0, 12.0, 2.0, 17.0, 7.5, 9.5, 6.0, 3.0, 7.5, 13.0, 4.0, 0.0, 1.0, 15.0, 9.5]
Got [] at src/lib.rs:26:9

AFAIK, rust tests are executed in parallel but are reported in alphabetic order, so it should simply be a matter of just naming them in alphabetic order. I know this from reading discussions on the discord server, not from experience, so it might not be fully accurate.

Hmmm, seems right. I didn't know that.

saudyGuy: do you want me to change the tests so they appear in order of difficulty? I don't think it's actually useful for the reasons I have explained, but it doesn't bother me either to change the design of the tests if you prefer.

If it can be easily implemented, please go ahead.

Done.

Initial solution: trait bounds Clone + Hash + Ord should be added to T.

The return type must be f64. f32 is not precise enough for big tests (it is possible to get different results if the sum is computed with f32 directly). More precisely, f32 is enough for this problem but the reference solution does not compute average ranks accurately (all ranks are either integers or integers + 0.5 but the reference solution may return 13583.501 or 20734.002 for tests with T = char).

I did the change. I was not sure about the output type. However, I don't understand how reference solution can return inaccurate results with chars especially (I think the result doesn't depend on the type of the input).

The following expression was the source of imprecision: sum::<usize>() as f32. This sum may become larger than the largest safe integer for f32 (2**24) if a value is repeated sufficiently many times in the original array. It is very likely to get this situation in big tests with chars because only 26 chars are used.

Indeed.. Damn floats! Thanks for the explanation!

Since this is a 7kyu kata, let's keep things simple. Random inputs will generate single characters only.

I am not sure it will be approved as 7kyu. The problem is actually that the description says Expect numbers and lower-case alphabetic characters only. while some fixed tests provide an array of strings. This should be aligned, and there is no reason random tests don't provide all the types one can find in fixed tests. In this case, you may also choose to remove/change the tests including strings with multiple characters.

Also, I don't think it adds difficulty to the task using chars or strings, a single comparison works (at least in Python and Rust, and many languages; I saw rowcased only uses unsigned ints in his translation, which may be a reasonable choice since handling multiple types is not easy in C).

I have removed strings from both the fixed and full test suites. I believe that generating strings will reduce the likelihood of duplicate values, which is the primary purpose of this kata.

You're always welcome to edit the Python version as well. I would be happy to learn from you guys.

Well, I am sure I don't need to teach you how to insert dupe strings randomly in an array ;)

For me the kata is ok, I don't see currently how to improve it really.

7kyu kata should not have performance requirements. The kata should be reranked ( ask a mod ) or the performance requirement should be removed.

Note that I haven't even solved the kata; I am just going off the description, the tags ( which don't include performance ?!? ), and this comment.