Very technical kata.

done

Can't edit top post now, the structure guidelines are here: https://docs.codewars.com/authoring/guidelines/description#structure

• Sample tests noItemsJustMoreTimesDeclared and someNoValuesAsWellAsSomeHaveValuesAssigned are expecting incorrect results
• Please remove unexplained weird special cases like "empty data containers"
• Author's solution occasionally but reproducibly times out. The performance tests need to be more lenient.
• Please provide number of random tests and input size in kata description.
• Please use Markdown formatting and follow kata description [structure guideline]. The current conversational style has a lot of useful information but it's poorly formatted, completely mixed up, and mixed in with a lot of unnecessary words, so it's very difficult to refer to when coding.

Some possible improvements

• Better feedback in random tests: Consider adding a print every, say, 100 tests to let user know how much more to optimize.

More comments in spoilered comment below:

:) Well done!
So glad to see this, though it has been 4 years since then and I am no longer able to spare time to finish the authoring of this kata. But anyway this problem and the solutions to it has their own aesthetic value.

It might be nice to add a note to the task description that the algorithm should perform well in the worst possible scenarios. I was expecting the input cases to be more random where some specific spatial data structures could be useful but then I saw this mesh of death with ~20k intersecting lines 😅 I wish I had known this test beforehand 😄

Also please check the most recent fork to see a solution that bypasses all this faff in the first place :)

The way AtomicU32 is used here doesn't make sense. Using static mut in multiple threads without other synchronization is straight up undefined behavior, and get_mut completely defeats the purpose of atomics in the first place.

static TESTCHECK: AtomicU32 = ... and fetch_add is probably what was intended. See: https://doc.rust-lang.org/std/sync/atomic/struct.AtomicU32.html#method.fetch_add

So basically the call of list-function in the second print statement is what messes up the code functionality.
Can someone explain why? Does it end the function somehow and if so: why?

Anyone reading, feel free to continue discussing, but since this has nothing to do with improving the kata I'm marking this as resolved.

The number of random tests for Java needs to be increased.

This solution fails roughly once every 20000 random tests (estimated), but it often passes as there are only 150 random tests currently.

I tried my hand at making an appropriate C translation.

Since this is my first C translation it should be reviewed carefully.

For the "rectangles located far away" test, I printed out the input as my solution was not efficient enough for it. By doing so, I realised that the coordinates of the last rectangles do not respect the condition: 0 ≤ xi, yi ≤ 1,000,000.

I'm not complaining or suggesting that this is the reason my solution doesn't work; I'm simply pointing it out.

I suppose a slightly more detailed explanation is in order. Neither of the two changes the resulting binary at all; it's purely an aesthetic concern.

For the and/andi one, yes the assembler is being permissive here.

For the li one...

The compressed instruction extension has 16-bit versions of c.mv and c.li. However, the source of c.mv cannot be x0/zero. The assembler here helpfully transforms mv a0, 0 into addi a0, zero, 0 then into c.li a0, 0, but I'd want li here to remind us that this is closer to how the instruction gets encoded.