Abusing native number types to trivialize a problem
It is common practice to restrict challenges to cases where input, output and/or intermediate values of the algorithm of choice fit into the language's native number type. At least for input and output, this is generally assumed even if not stated in the challenge specification.
There are at least two ways to abuse this:
Using a language like Boolfuck which only has a 1-bit integer type.
With one bit of input and one bit of output, there are only four different Boolfuck programs that can solve all challenges.
I'm fairly certain this has been done more than once, but I can only find this answer right now.
Deliberately exceeding the precision limit.
I don't know if this has been done before, but one could start by computing A(4, y) for input y (a 19,728 digit integer for input 2), and then do anything that works for inputs 1 and 0.
As a rule of thumb, I'd say an answer abuses the native number type if the code would require non-trivial modifications for larger number type.
Implementing bit rotations as
(x << n) | (x >> (32 - n))
for 32-bit integers is allowed; only the
32has to be changed to make it work for, e.g., 64-bit integers.
Hardcoding a list of the prime numbers below 128 is not allowed in a challenge that involves primality testing, even if the language of choice only supports signed 8-bit integers.