[Accountant] Bug in the simulation and data?

Feedback & Bugs
#1

Hi,

I’ve encountered two possible bugs in the Accountant competition. A perfect simulation is a must in this competition, however I’m unable to create a perfect match with the on-site simulation.

Here’s a case, Validation 9: My simulation differs in a way which is strange: y coordinate of an enemy differs: it is one less in the on-site simulation. What is strange, when it happens, no data points are picked up yet. When the difference happens, in my simulation, enemy.coord.y==enemy.prevCoord.y==enemy.targetCoord.y. So this enemy must go in a straight horizontal way. However, in the on-site simulation, he goes 1 unit upwards!

Can you please confirm that the on-site simulation is perfect, and it is a bug in my code (If there’s a bug in the on-site simulation, I don’t want to waste more time on this)?

The other bug I noticed is that the validation set contains coordinates with x==16000 or y==9000, which are invalid according the rules.

A suggestion: can you please add the information why a game is failed? Timeout/0 score/death etc.?

Thanks,
Geza

3 Likes
#2

I’m having the exact same issue on validation 9, so any info on that would be appreciated. I’d also like to second the suggestion for more info on failed test cases.

#3

By target coord do you mean the data point’s coordinates, or the enemy’s next coordinates?

#4

Data point’s coordinates. I’ve analysed this issue a little bit further, this bug happens at the first step: after the first step, the enemy y coordinate is one less than it should be.

#5

I haven’t ran into this problem, could you possibly get the relevant initial enemy and data point coordinates? It would be easier to analyze what the enemy movement ought to do

#6

It would need a lot of submits, so I’d rather not do it. But thanks for the suggestion!

#7

See test case 11.

enemy 0 initial position: (15500, 1000)
data point 0 position: (13000, 1000)
enemy’s next position: (15000, 999).

Maybe they’re working with angles and suffering from floating point error. For example:

float angle = atan2(0.0, -2500.00);
printf("displacement: %f %f", 500*cos(angle), 500*sin(angle));

Mathematically this should obviously show a y displacement of 0, but as a float the angle happens to be slightly below π radians, so the y displacement becomes -0.000044. Adding that to the enemy’s initial y of 1000 and flooring it results in 999.

A way to calculate displacement based on vectors without these seemingly random rounding errors:

double dx = x1 - x0;
double dy = y1 - y0;
double hyp = sqrt(dx*dx + dy*dy);
double new_dx = 500.0 * dx / hyp;
double new_dy = 500.0 * dy / hyp;

edit: Maybe they’re not using angles like I thought, since enemy 0 and enemy 1 are both moving in the direction PI but only one of them has the off by one error O_O

#8

I have made the same observations. It’s really anoying. I’m coding in C#.

Even in the second test there is an error.
Enemy starts at 14500, 8100 and moves towards point at 8000, 7100.
It should move to 14006, 8024 but ends up at 14006, 8023

No difference if I use float, double or decimals.
I’m started to think that the internal positions are stored with decimals but are presented as rounded.

#9

On this one their math seems correct.

let dx = 8000 - 14500, and dy = 7100 - 8100. Then the magnitude m = sqrt(dx^2 + dy^2) = 6576.47321898. So y’ = 500.0 * dy / m = 8023.97140787 which floors to 8023. How are you calculating?

#10

Yes I’m with you there but the x is rounded up from 14005,8141511747 to 14006 so there is something wierd going on.

Here are the actual coordinates for the movement from 14500,8100 towards 8000, 7100

Interesting looking att the error column.

Expected	  Actual	Error
14006, 8024	  14006, 8023	0,1
13512, 7948	  13510, 7947	2,1
13018, 7872       13015, 7871	3,1
12524, 7796	  12520, 7795	4,1
12030, 7720	  12025, 7719	5,1
11536, 7644	  11530, 7642	6,2
11042, 7568	  11035, 7566	7,2
#11

I think you wrote down the coordinates wrong, I’m looking at test case 02 and seeing 14005 as we would expect.

edit: For the record my simulation agrees with CG perfectly for the first 10 test cases, so I don’t think there’s anything off there, unless we’re making the same mistakes.

#12

Yeah, I’m seeing 14005 as well, I guess I must have made some kind of error some were in the copy paste. I’m printing out json as debug so I guess i trusted my data a bit to much. Thanks

#13

Yeah, test case 11 produces exactly the same error I encountered in validation 9. It is so similar (my bot kills the misbehaving enemy at the same round) that it’s possible that validation 9==test 11.

Codingame, can you please fix this bug? Thanks!

#14

EDIT:
i withdraw my report …(until i can reacreate it)
i had a little mistake in my calculation … lets see if it is fixed now

I also have this bug with player movement made by the game engine

i tell my Character to move from 3015 3973 to 2148 3473
Sometimes i get to 2148 3473 and sometimes to 2148 3472

it’s almost a 50:50 chance

Before i had the same bug in my code sometimes it subtracted 500, and sometimes 500,00000000001
i got that fixed, but now i found the same bug in the game engine :frowning:

#15

Same here. It is very easy to see at #11 in debug mode:

Start frame: Enemy 0 starts at Y=1000 and moves towards Y=1000

Next frame: Enemy has Y=999…

To quote geza: Codingame, can you please fix this bug? Thanks!

1 Like
#16

Ok still happens

rad = 130 * Math.PI / 180 = 2.2689280275926285
difx = 1000 * Math.sin(rad) = 766.044443118978
dify = 1000 * Math.cos(rad) = -642.7876096865393
oldX 5569 floored new 6335
oldY 6269 floored new 5626

Predicted 6335 5626 actual 6334 5626

just to repeat it this is not enemy movement this is player movement

Here is a replay if it helps the CG people

The fail is because i throw an Exception if i get a difference between predicted and actual

#17

There is definitely an issue at the start of simulation in test case 11 “Surrounded”.

In this test case it just can’t be a rounding issue as the target data set Y coordinate is aligned with enemy’s one as listed in previous posts.

It’s quite unfortunate that the post pointing this issue out have been flooded with other erroneous reports and that make this topic quite a mess.

For now i’ll do like every body else and ignore it I guess. But that’s annoying to have something strange like that in the middle of the simulation that makes you feel it could happen at critical positions even if the probability is relatively low. It still actually made my debug check stall, well i’ll just do without the checks for the time being.

1 Like
#18

FredericBautista if the y dif is inited as a double with 0,000000000001 it would bring exactly the result they decribe above …
and double do things like this sometimes …

1 Like
#19

@MaximeC or someone else from the CG team, can you tell us why the above is happening and when it’s going to get fixed? After the first turn on ide test 11 the enemy at 0 lands on y=999 instead of staying on y=1000 when moving towards the data point at y=1000.

#20

Not with a standard behavior given as truncation to the lowest value at least.
And in any case we are given integer coordinates we can’t guess it.