*       in the hash code should be as evenly "spread out" through the hash code's bits as possible.
 *       The result is that, for example, when choosing a bucket in a hash table of size 2^8,
 *       <i>any</i> eight bits could be consistently used.
 *   <li><b>cryptographic:</b> certain hash functions such as {@link Hashing#sha512} are designed to
 *       make it as infeasible as possible to reverse-engineer the input that produced a given hash

 *       in the hash code should be as evenly "spread out" through the hash code's bits as possible.
 *       The result is that, for example, when choosing a bucket in a hash table of size 2^8,
 *       <i>any</i> eight bits could be consistently used.
 *   <li><b>cryptographic:</b> certain hash functions such as {@link Hashing#sha512} are designed to
 *       make it as infeasible as possible to reverse-engineer the input that produced a given hash

which also adds an initial environment dump to the beginning of the log.

Note also that in reported output, the actual name of the per-script temporary directory
has been consistently replaced with the literal string $WORK.

The cmd/go test flag -testwork (which must appear on the "go test" command line after
standard test flags) causes each test to log the name of its $WORK directory and other

   *
   * <p>The {@code hash} has the following properties:
   *
   * <ul>
   *   <li>It is <i>consistent</i>: for any reference {@code x}, multiple invocations of {@code
   *       hash(x}} consistently return the same value provided {@code x} remains unchanged
   *       according to the definition of the equivalence. The hash need not remain consistent from

   *
   * <p><b>Note:</b> if you won't be adding any elements to the list, use {@link ImmutableList#of()}
   * instead.
   *
   * <p><b>Performance note:</b> {@link ArrayList} and {@link java.util.ArrayDeque} consistently
   * outperform {@code LinkedList} except in certain rare and specific situations. Unless you have
   * spent a lot of time benchmarking your specific needs, use one of those instead.
   *

   *
   * <p><b>Note:</b> if you won't be adding any elements to the list, use {@link ImmutableList#of()}
   * instead.
   *
   * <p><b>Performance note:</b> {@link ArrayList} and {@link java.util.ArrayDeque} consistently
   * outperform {@code LinkedList} except in certain rare and specific situations. Unless you have
   * spent a lot of time benchmarking your specific needs, use one of those instead.
   *

					}
				}
			}
		}
		return true
	})
}

// fixAtPosCall updates calls of the form atPos(x) to x.Pos() in argument lists of (check).dump calls.
// TODO(gri) can we avoid this and just use atPos consistently in go/types and types2?
func fixAtPosCall(f *ast.File) {
	ast.Inspect(f, func(n ast.Node) bool {
		switch n := n.(type) {
		case *ast.CallExpr:

	// conversion that must result an empty object and practically is the same as nopConverter.
	// A smoke test in API machinery calls the converter on empty objects. As this case happens consistently
	// it special cased here not to call webhook converter. The test initiated here:

      int n = rand.nextInt(Integer.MAX_VALUE);
      assertEquals(LongMath.isPrime(n), IntMath.isPrime(n));
    }
  }

  private static int force32(int value) {
    // GWT doesn't consistently overflow values to make them 32-bit, so we need to force it.
    return value & 0xffffffff;
  }

    }
    int div = p / q;
    int rem = p - q * div; // equal to p % q

    if (rem == 0) {
      return div;
    }

    /*
     * Normal Java division rounds towards 0, consistently with RoundingMode.DOWN. We just have to
     * deal with the cases where rounding towards 0 is wrong, which typically depends on the sign of
     * p / q.
     *