Problem Link
Has any one solved this problem recently? All the expected value problems in Mathematics section seems to have weird test cases. It is very irritating. No matter how i handle the precision it is getting wrong ans in some test cases everytime for the last digit in the answer. If any one has solved it in recent time (mayb more test cases were added) please do share your code here. Thanks in advance.








do
cout << fixed << setprecision(6);before the answerI think there are faults in test cases. No code seems to get accepted completely in this problem due to mismatch in the 6th digit.
can you show your code instead of blaming the problemsetters, 1527 people ahve somehow solved it despite the supposed 6th digit bug
That's what i am saying that new test cases have been added and if someone has solved it in recent times. I could be wrong but this is the code. I tried different variations but all failed in some test cases.
I thought the input only contained n and k
I made a mistake with the problem name and Link. I corrected them. The problem is Inversion Probability. Though same issue was faced with Candy Lottery but that was only one test case so i hard coded it. But in Inversion Probability problem (the one i gave) multiple test cases are failing for precision.
I solved candy lottery very recently (I guess less than 1 week ago). The same for the robots problem that also involves expected value. There were no issues with precision in any testcase.
I just tested it myself and yeah it seems there is a problem with the checker.
My first submission had
setprecision(6)and it gave me a WA for53.418336instead of53.418337. Another submission hadsetprecision(8)and it WA'd on all test cases. It seems the checker just sees if the output matches the correct answer exactly without treating them as numbers.The 0.000001 discrepancy appears to be differences in how rounding is handled. that earlier testcase appears to be exactly
53.4183365000000. The server appears to be inconsistent about which way it wants rounding to happen, neither rounding up nor down nor to even seem to work.yeah kinda like that
I checked test case 15 (which my code WA'd on) and wrote a python program to find it as an exact fraction and it was $$$\frac{2831421530641709}{53004674352630}$$$. Which is equal to
53.4183365000000000000943313030608574746(That is not a float error it really is just a weird value!) so technically rounding to 53.418337 is correct here but realistically nobody's gonna solve that because it becomes a float mangling problem instead of a mathematics problem.After a lot of attempts, I was able to pass all the test cases — without hardcoding or other trickery. If you want to pass all the testcases without recurring to that sort of method, I suggest you use python and compute the exact answer, using rationals. I used the decimal module to calculate the answer at the end. It has the rounding type we need (ROUND_HALF_EVEN) and you can increase the precision if necessary.
Thanks bro. After converting to Python and using Round_half_even it FINALLY got accepted :)
peak competitive programming