Coding Games and Programming Challenges to Code Better
Send your feedback or ask for help here!
In case this bites anyone else…
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.
My solution does not use powers.
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.
Yes, I have been sufficiently humbled. Thank you.
As I have said before, this is the place to make such mistakes, and learn from it. I’d rather make an idiot of myself in solving a CG puzzle than in the workplace.
Good call. Looks like TPTB have taken your suggestion.
FYI, the largest number in this puzzle is:
4 052 555 153 018 976 266
or if you multiply out 3^39:
4 052 555 153 018 976 267
This is less than half of 9*10^18:
9 000 000 000 000 000 000
So the problem statement is correct. Even so, yes, these are very big numbers.
Sorry, my bad, I have miscounted the digits Nevertheless, the generated code should use Long and not Int.
I agree.