Number of elements = 20000

[[1, [2, 8], 532, 532], [2, [9, 15], 917, 1449], [3, [16, 22], 966, 2415], [4, [23, 29], 960, 3375], [5, [30, 36], 1296, 4671], [6, [37, 43], 1386, 6057], [7, [44, 50], 1592, 7649], [8, [51, 57], 1903, 9552], [9, [58, 64], 1945, 11497], [10, [65, 71], 1887, 13384], [11, [72, 78], 1884, 15268], [12, [79, 85], 1895, 17163], [13, [86, 92], 1603, 18766], [14, [93, 99], 1194, 19960]]

should equal

[[1, [2, 8], 532, 532], [2, [9, 15], 917, 1449], [3, [16, 22], 966, 2415], [4, [23, 29], 960, 3375], [5, [30, 36], 1296, 4671], [6, [37, 43], 1386, 6057], [7, [44, 50], 1592, 7649], [8, [51, 57], 1903, 9552], [9, [58, 64], 1945, 11497], [10, [65, 71], 1887, 13384], [11, [72, 78], 1884, 15268], [12, [79, 85], 1895, 17163], [13, [86, 92], 1603, 18766], [14, [93, 100], 1234, 20000]]

I don't know if anyone else had this problem, but the only errors I get are similar to this result, somehow the code computes the last upper value to be 99 instead of 100. But I swear if I run the same code on spyder with A = 7 and k = 14, for this example, it computes 100 correctly.

Bruteforce is not the right approach at all. Try something clever which does not generate a bunch of stuff that is gonna be rejected anyway. Generate only the increasing numbers perhaps, not all of them

non-decreseasing order sounds better, than increasing order with possible duplicates. Maybe you could change that to make the description clearer

My fault, you are right.
Thank you for the great Kata!

with 259 JavaScript completions it is unlikely that there is such a glaring issue in the tests.

maxSumDig(16409, 3) [...] maximum value for this case is 12000

no, the maximum value below 16409 is 12001 because 1 + 2 + 0 + 0 = 3; 2 + 0 + 0 + 1 = 3

fixed here

fixed

Javascript: In random tests I get maxSumDig(16409, 3) => expected [ 40, 10000, 283897 ]
But it is wrong, maximum value for this case is 12000 and correct response should be [30, 3000, 178332]

BTW for all random tests I have same issue.
Thanks.

the constraints should be way bigger for a 4 kyu

there is a typo in the OCaml description:
find_all 10 3 => Some (8, 188, 334) should be find_all 10 3 => Some (8, 118, 334)

done

thanks :)

Java: JUnit is not used properly. Test names are logged to the console instead of meaningful test methods' names, and arrays are compared by their string representations instead of with assertArrayEquals()

fixed here + upgrade to JUnit 5 + better assertion messages

Java is not using JUnit properly, tests' names are logged to the console instead of using method names / @DisplayName. fixed here + better assertion messages + upgrade to JUnit 5