Could someone advise whether I am misinterpreting the instructions, or whether this is an incorrect test:

# printed args (with multiple lines of the data arg removed to make it more concise)
data = [
    ...,
    (92, 3231),
    (2332, 92),  # used in P  # 2332 is a friend of the prince
    (92, 7178),
    (8138, 8473),
    (92, 2690),
    (9248, 2332),
    (92, 9883),
    (92, 5203),
    (698, 4683),
    (698, 4515),
    (81, 5122),
    (81, 1537),
    (5290, 1858),
    (9782, 5290),  # used in P
    (5290, 698),  # used in P
    (698, 3582),
    (698, 1922),
    (81, 92),  # used in P
    (81, 6645),
    (9782, 2332),  # used in P
    (8138, 4800),
    (81, 6611),
    ...,
]
prince_id = 92
thief_id = 698

The test result says 81 (among other similar examples) should be included in the output.

The rows with # used in P noted appear to be used in a path ([698, 5290, 9782, 2332, 92, 81]) which contains a friend of the prince (2332). This leads me to believe the ID of 81 should not be included as per the formula in this section in the instructions:

To explain this mathematically, denote $F$ as the set of friends of the prince.
Let $f \in F$ be the friend of the prince and $t$ the thief of the treasure. Now,
denote $P^t_f = { p_1, \dots, p_n}$ as the set of all the people in a
friendships path between $t$ and $f$ excluding them. $f$ is a suspect if and
only if there is a path between $t$ and $f$:

$t → p_1 → p_2 → \dots → p_n → f$ such that for all $p \in P^t_f$ , $p \notin F$

Is it simply that the end of the formula is not accurate ($ p \notin F $), or am I mistaken?

The fixed tests are not fixed, they are relying on the ref solution. Meaning if the ref solution is wrong, there is no guarantee on the specs. At all.

Also, the fixed tests should hold all the needed data for each test in one place: input data, princ and thief ids, and also the expected output. The sample tests need to also be updated with this.

Who the hell reviewed the random tests and didn't notice THIS:

def create_subgraph(id_, amount_friends, not_possible = set()):
                                       # ^^^^^^^^^^^^^^^^^^^^

Hi,

Something isn't specified "correctly", apparently, but more importantly, the efficiency tests are using some outputs that are built entirely differently of all the other tests (edit: that, or the problematic case comes up more frequently when the number of nodes is huge): I currenlty have a solution (fast enough) that is passing all the tests, but returns wrong results on some efficiency tests only. Problem being: how am I supposed to find the hidden spec/stuff I misunderstood on inputs with more than 4000 nodes...?

Tests should fail without raising exceptions when the result is not iterable.

Reading the discussion below, I think the description should use "index" instead of "element", because the whole "indistinguishable" only makes sense when you completely ignore the actual elements in the array.

Rust:

1. The initial solution function should be

fn get_jumps(cycle: Vec<i32>, k: i32) -> i32 {
    todo!()
}

2. All test code should be defined inside the module tests (right now it is possible to call the gcd function defined in tests and it is not possible to redefine it).

I think because of drafting this kata wasn't updated to 3.11 and stuck into 3.10; made a fork with update to 3.11

Your solution must be in O(1)

This is a lie: even the author solution is O(log(t)).

Any other solution that pass all the tests may differ from the reference solution because of the accumulation of numeric errors

It should be noted that the expected result is incorrect: forecast_population(1000,800,40_000_000,(0.05,0.2),(0.0000005,0.0000005) should be (698634388210.59, 174658597052.65), not (698634383958.54, 174658595989.64).

Frankly speaking, rounding to 2 decimal places is completely wrong for two reasons:

• The rounding boundary still exists even with 1 cycle: e.g forecast_population(1,5,1,(0.3,0.2),(0.025,0.015)) can easily give (1.7249999999999999, 4.375) which would round to (1.724, 4.375) instead of (1.725, 4.375)
• Tests with a big t (especially in the random tests) will generate a value so large there is no "2 decimal places", e.g (2.3734649910435697e+19, 2.221405859431348e+19) should equal (2.373464977977128e+19, 2.221405847202025e+19)

Also, in random tests arbitrary floats are passed in anyway, so testing exact float equality is nonsensical.

(Also, to kata author: your solution is numerically unstable: it results in an error about 10^-8 from the actual value. Please replace it with something numerically stable and actually accurate before replacing the equality with approximate equality; otherwise still nobody can pass your tests.)

percentages: (tuple) as (α\alphaα, β\betaβ) where α\alphaα is the percentage of the population that migrates from KKK to SSS and β\betaβ the percentage of the population of S that migrates to KKK

Percentage goes from 0 to 100, but the example tests show these two values going from 0 to 1, so they're just ratios and aren't percentages.