Specifically, we did 23, not 19.

Great job! Please PM me your mail address so that I can send you something. =)

It could be! I didn't read the entirety of WWFYMP and didn't see this problem there. There is a similar problem in ONAG (Conway's On Numbers and Games) with triminoes instead of dominoes. The triminoes game is kinda complex, but happily the dominoes game can be analysed with relatively simple tools.

Thx, I did just that, I guess I had overflow :p

Very nice, thanks!

Hello :). So as I imagined such robot following rom real life, I imagined that it should go more or less straight and make corrections to his direction on the fly. After mnbvmar explained his approach to me, I realized I was not very creative, because his was substantially different and obviously better, but it looks like mine also can be made to kinda work.

I think that seeing my code may help understanding what I did, so here it is: https://ideone.com/yenxK5 Relevant part starts from line 894 (xD) (disclaimer: my comments may be kinda misleading). Let me firstly decribe how I made it to follow simple straight line. I made three modes of work: "go straight", "return with one wheel to track" and "while on track but rotated significantly, fix it".

1) If sum of two sensors is big (>1.8) then I simply go straight.

2) If it isn't, but one of sensor's reading is big then I try to fix position of that wheel which is out of track by doing either Go(0, 0.5) or Go(0.5, 0).

3) If both sensor readings are small then both wheels are on track but whole robot is significantly rotated from its desired direction. Assuming my sensor readings are accurate I may determine angle by which it is rotated, but I can't determine whether it is rotated left or right. In order to determine this I go little back and forth (Go(-0.3, -0.3) and Go(0.3, 0.3)) and see which sensor reading decreased and which increased which helps me to determine this. Btw sometimes if I'm unlucky these perturbations may significantly broke this part, but I can validate if what I got is sane and it it isn't, I repeat this step. After that I try use few calls of form Go(x, x) to put center of my robot to polyline and then rotate it by appropriate angle that I already know.

For polyline which is a straight segment this already works really well and uses small number of steps (~10000 for segment of length 4000). However turns are really troublesome to that approach. If my robot is in one of first two modes it is still fine for him to perform corresponding moves, but as it is right now it can go crazy in third mode. I understood that main problem is that part with determining angle of rotation where I use Go(-0.3, -0.3) and Go(0.3, 0.3) because being close to next turn may significantly lower one of my readings which will make my computations rubbish. If there's no turn blose to me I expect that Go(-0.3, -0.3) will increase add correspondingly x and -x to my sensor readings. for some significant x (either positive or negative, but not very close to zero). If I see that this is not the case then I conclude that I am close to turn and turned in more or less good direction, so I do Go(1, 1) in that case (lines 926-930).

Best what I got locally was something like never passing 10th test (but able to sometimes pass ~150 out of 300 points), sometimes passing 9th sometimes not and passing all the rest. But with really tiny change to this code and seed it was passing 8 points on both 9th and 10th test xd.

mnbvmar's approach was much better. He basically was standing still with one wheel and dragging second one along halfcircle. In other words, alternately doing groups of Go(1, 0) and groups of Go(0, 1) moves. Within every group he was doing it until that moving wheel falls on track again. He said that his approach was very robust in a meaning that once he coded it correctly it immediately passed all tests, but just with a little bit too many steps (~20500), so he was doing something like Go(0.05, 1) instead of Go(0, 1).

Regarding my thoughts about this problem. They are kinda mixed. It is really an unconventional one and kinda fun, but once everything is more or less fine there is a big possibility of drowning into small details, investigating what went wrong in our 10th attempt etc which may be a black hole of suffering. When sitting at home coding New Year contest it can be tolerated, but on ACM, one of possibly most annoying things is hearing your teammate saying for the 10th time "allow me to code, just one more fix and it will surely work!" — in this problem it would be kinda unavoidable. I really felt relieved when I completely unexpectedly got random OK :P. Nice experience to have it once, but solving such on regular basis would be tiring. But maybe this was just my punishment for taking a wrong approach to it instead of much clearer one that Marek came up with.

Btw I was also kinda annoyed that having a visualisation to this problem would really help, but I was unable to make it because I couldn't have spent as much time on this problem as it would require in my case. Getting to know what went wrong would be much easier. I think it could be a good idea if there would be a dedicated tool for this prepared in advance by organizers.