The description should disclose number of tests: 30 tests up to 1000 soldiers each. This would allow to deduct that any HashMap solution will likely not pass.

Rust code does not take into account that Balzer starts from the last element.

Modifying initial tests squad[0] = TRIGGER_STATE; to squad[size-1] = TRIGGER_STATE; does not help, because the final tests have it hard-coded as well.

The same problem may exist in other translations.

The final tests contain 50 tests with ~1k elements and 10 tests with ~20m elements. Make sure you can pass all within the timeframe of your language.

I think the longest mountain pass in your example is [1,2,3,4,6,6] so the answer should be (6,2), because 5=(2-1)+(3-2)+(4-3)+(6-4)+(6-6). No?

Incorrect assert message in Rust:

assert!(actual == expected, "Expected score with dice {dice:?} to be {actual}, but was {expected}\n");

Actual should be swapped with expected.

Rust tests expect power_sum_dig_term whereas the sample function has uppercase characters.

Would it be possible for someone to fix Rust?

To be clear, there is an unwrap here: 0 inside fold is the default value. Same you could write as .max().unwrap_or(0) , which is also correct error handling. .unwrap() is what you should never use...

When attempting to pass Rust the error message says that my code returned an empty array. When I insert the same input into initial tests the code runs fine and returns data. There is something wrong with final tests.

Very interesting challenge and outstanding error messages for Rust. Rank rating disproportionate to time required.

Rust contains incorrect module name use num::bignt::BigUint;, should be use num::bigint::BigUint;.

I think to be fully correct there also has to be a test case with rate 0.0.

Deprecation warning in Rust (tests use an outdated function):

warning: use of deprecated associated function `chrono::NaiveDate::from_ymd`: use `from_ymd_opt()` instead
  --> src/lib.rs:54:36
   |
54 |         let mut first = NaiveDate::from_ymd(year, 1, 1);

I guess the "performance" tag is absent, because one needs a solution a bit better than a full scan. However, due to number of timeout complaints below, it is debatable. Maybe the description should be updated to clarify which solutions are expected?

It would be good to know the number of tests and the limits for input values - it seems the limits are language-specific. Even better would be to have a stress-test in initial tests as well to show which solutions should not pass.

According to the author divisors of 27 are 1,3,9,27, not 3,3,3. Due to this 26 (1,2,13,26=2·13) and 27 (1,3,9,27=3·3·3) form a match. I think the description should clearly state that one divisor is being taken only once, so people do not confuse it with factorization.

Rust tests expect 69.99373876010293 to be 69:60, whereas it is 70:00.