Yes, it seems I had same issues as you had. The takeaway is “do not calculate it in whatever Int/Bigint/etc your language uses by default” but instead “use 32-bit unsigned integers for all intermediary variables and constants”. That seems to be the only way to do it, anyway.
A similar takeaway seems to be do not use languages that use Floats/Doubles/etc for computation on integers. I am pointing onto the gentleman above who used TypeScript.
I’m failing the last validator. Can anyone give me a hint or the input for it?
You’ve found and fixed the issue after posting the message, right? 
Yes I found it 
I had an array of size m (num mines to place) where each element contained was a tuple containing x and y of all yet placed mines. When I was generating the mine positions I was checking the array if there is already a mine. What I didn’t had in mind was that the whole array was initialized with 0,0 x,y entries. In the last validator I rolled a mine on pos 0,0. I checked the array and detected a mine at 0,0 but this was an error. I’ve replaced that array with a List that grows dynamically and the error was fixed. Thanks for all the people in the discord that pointed me in the right direction
Always same position for first test.
1 0
1 4
5 3
2 4
…
The 4th it’s incorrect.
Test in Rust, C, C++ (all 3 with u32 variable) and Python (for fun with modulo ich 2^32).
Someone has done in this language ?
EDIT :
Ho reread the statement… problem was to an other place…
Note, with bit-and, it’s easy in Python (and other language).
Note (2), i’m oppose to puzzles with overflow mekanism; never be a good pratice in any language.
Hello,
It seems i did not understand this puzzle.
I implemented in C++ with unsigned int to generate numbers.
For the first test, i got the 4 first (x,y) but not the 5th…
I listed the map with 7 mines and the checked (x,y).
If anyone can give me an idea ? Many thanks in advance
x: 1 y: 0 1 0
x: 1 y: 4 1 4
x: 5 y: 3 5 3
x: 2 y: 4
x: 4 y: 4
x: 4 y: 0 4 0
x: 2 y: 2
x: 2 y: 3
x: 3 y: 4
x: 4 y: 4
x: 4 y: 4
x: 4 y: 1 4 1
x: 4 y: 2
x: 2 y: 2
x: 2 y: 0 2 0
x: 2 y: 3
x: 3 y: 0 3 0
.####.
....#.
......
.....#
.#....
......
After x: 2 y: 4, I got x: 4 y: 0 instead of y: 4.
I was helped in MP to solve it.
I did not increment the generation if a mine was not validated after y.
Yes, you are right. Thanks.
Struggle for those who use languages which don’t support unsigned types and practice in typing for C(++/#) coders. Strange “puzzle”.