Skip to main content
Code Golf

Return to Answer

I think that's what this means
Source Link
ETHproductions
ETHproductions
  • 50.1k
  • 30
  • 27

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:

  1. 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.

    So far, at least two answers have done this:

  2. 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 2y = 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.

Examples:

  • Implementing bit rotations as

      (x << n) | (x >> (32 - n))

    for 32-bit integers is allowed; only the 32 has 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.

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:

  1. 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.

    So far, at least two answers have done this:

  2. 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.

Examples:

  • Implementing bit rotations as

      (x << n) | (x >> (32 - n))

    for 32-bit integers is allowed; only the 32 has 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.

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:

  1. 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.

    So far, at least two answers have done this:

  2. 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 y = 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.

Examples:

  • Implementing bit rotations as

      (x << n) | (x >> (32 - n))

    for 32-bit integers is allowed; only the 32 has 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.

edited body
Source Link
Weijun Zhou
Weijun Zhou
  • 3.7k
  • 7
  • 10

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:

  1. 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.

    So far, at least two answers have done this:

  2. 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.

Examples:

  • Implementing bit rotations as

      (x << n) | (x >> (32 - n))

    for 32-bit integers is allowed; only the 32 has 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.

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:

  1. 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.

    So far, at least two answers have done this:

  2. 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.

Examples:

  • Implementing bit rotations as

      (x << n) | (x >> (32 - n))

    for 32-bit integers is allowed; only the 32 has 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.

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:

  1. 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.

    So far, at least two answers have done this:

  2. 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.

Examples:

  • Implementing bit rotations as

      (x << n) | (x >> (32 - n))

    for 32-bit integers is allowed; only the 32 has 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.

replaced http://codegolf.stackexchange.com/ with https://codegolf.stackexchange.com/
Source Link
Community Bot
Community Bot
  • 1

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:

  1. 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.

    So far, at least two answers have done this:

  2. 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.

Examples:

  • Implementing bit rotations as

      (x << n) | (x >> (32 - n))

    for 32-bit integers is allowed; only the 32 has 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.

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:

  1. 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.

    So far, at least two answers have done this:

  2. 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.

Examples:

  • Implementing bit rotations as

      (x << n) | (x >> (32 - n))

    for 32-bit integers is allowed; only the 32 has 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.

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:

  1. 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.

    So far, at least two answers have done this:

  2. 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.

Examples:

  • Implementing bit rotations as

      (x << n) | (x >> (32 - n))

    for 32-bit integers is allowed; only the 32 has 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.

added 124 characters in body
Source Link
Dennis Mod
Dennis Mod
  • 210.6k
  • 5
  • 94
  • 168
Source Link
Dennis Mod
Dennis Mod
  • 210.6k
  • 5
  • 94
  • 168
Post Made Community Wiki by DennisMod