The stub generator for Fractal Carpet reads int from the input. I needed to change this to long in C# to be able to read the last test, and it turns out that the final validator needs a ulong. Also, even with this change, I was failing the final validator because I was using Math.Pow() in my solution, and it returns a double. At the size of the numbers in use, double does not provide enough precision. I needed to change my code to call BigInteger.Pow() instead.
I’m providing this information just in case (like me) someone can’t figure out why all the tests pass, but the last validator fails.
I’ve helped out a fellow on the chat yesterday who had the exact same problem in C or C++, so yes, I think it’s going to be useful.
IMHO using floating point pow() is the user’s own damn fault and good as is; but it is notable that the final validation case, though within constraints, is orders of magnitude bigger than the final test case, and indeed enough to overflow a double’s mantissa.
My easy recommendation for TPTB would be to just swap test and validation for the final case. Both overflow the naive approach anyway, so no need to keep the floating point resolution surprise hidden.
I had problems with this puzzle too. In the description, X and Y are considered to be Long, i.e. less than 9*10^18. However, the generated code do not use Long (I program in Scala) but Int. Moreover, for the last test, number higher than Long are sometimes generated (which is supposed to be impossible). So, finally, I had to use BigInt just to be able to read data.