You register via the process described there.

I'm having the same problem with aspen. Kattis won't accept my answer even after rounding exactly like in the examples. Any help would be appreciated!

I have double-checked and Kattis does use the stated absolute/relative tolerance.  So printing the answer with 6 digits and rounding either way will be sufficient (and adding a few more digits to the output doesn't hurt).

In other words the output formatting is not the likely culprit, but there is probably some other bug, either in the algorithm, or in its implementation.  I can try to give more concrete hints if I get a Kattis submission ID.

(PS regarding ljutnja I just answered on that post, but do note that what you write here about the answer having to be truncated to a 64-bit integer is not correct.)

Thank you for the answer!

Could you take a look at ID 766056 then? All the test cases i try just give me correct answers to the last decimal.

Also: I commented the ljutnja post and double checked. There is something strange going on having to do with 64 bit integers, as i can get the correct answers simply by taking mod 2^64 to my existing python algorithm, which otherwise gives "wrong answer" on Kattis.

Johan, here is a hint: some parts of the C/C++ standard library do not behave the way you might expect them to, make sure to use the right functions.

Ok, thank you! I am quite new to c++ so this is very likely.

TIL i learned that std::abs is very different from abs. Sometimes.

Per Austrin: I think I have a related issue with the tolerance/precision when running in Java. Could you look into ID 790961?

Hi Johan!  Your issue is not related to tolerance/precision.  You should probably try to convince yourself that your algorithm is correct.

It means that you can assume that the input satisfies the property that the correct answer, which is an integer, lies between 0 and 18446744073709551615 (inclusive).

(I'm not really sure what you mean by "give the answer in a 64-bit unsigned integer": you always give the answer as a string of digits.)

I might be wrong, let's double check. Compare my submissions id 756596 and 765908:

In both i print the answer using python 3.4 integers which have "unlimited" precision. In one i take the answer mod 2^64. I get correct answer in the one using modulus. I suspect this means that there is a test where the correct answer is larger than 2^64. Such a testcase is possible, e.g. all children want 2*10^9, there are 10^5 children, and only 1 candy, yielding about 22000 times more anger than can fit in a 64 bit unsigned integer. Correct?

Good catch, thanks!  The test data for the problem indeed contained some invalid test cases where the correct answer exceeded 64 bits.

I have fixed this, and all old non-Accepted submissions are currently being rejudged -- your initial submissions using unlimited precision will switch state to Accepted in a little while.

If you have questions about the problem formulations, please ask them here.