The quality of implementation specifications concern two * properties, accuracy of the returned result and monotonicity of the * method. Accuracy of the floating-point {@code Math} methods is - * measured in terms of ulps, units in the last place. For a - * given floating-point format, an {@linkplain #ulp(double) ulp} of a - * specific real number value is the distance between the two - * floating-point values bracketing that numerical value. When - * discussing the accuracy of a method as a whole rather than at a - * specific argument, the number of ulps cited is for the worst-case - * error at any argument. If a method always has an error less than - * 0.5 ulps, the method always returns the floating-point number - * nearest the exact result; such a method is correctly - * rounded. A correctly rounded method is generally the best a - * floating-point approximation can be; however, it is impractical for - * many floating-point methods to be correctly rounded. Instead, for - * the {@code Math} class, a larger error bound of 1 or 2 ulps is - * allowed for certain methods. Informally, with a 1 ulp error bound, - * when the exact result is a representable number, the exact result - * should be returned as the computed result; otherwise, either of the - * two floating-point values which bracket the exact result may be - * returned. For exact results large in magnitude, one of the - * endpoints of the bracket may be infinite. Besides accuracy at - * individual arguments, maintaining proper relations between the - * method at different arguments is also important. Therefore, most - * methods with more than 0.5 ulp errors are required to be - * semi-monotonic: whenever the mathematical function is - * non-decreasing, so is the floating-point approximation, likewise, - * whenever the mathematical function is non-increasing, so is the - * floating-point approximation. Not all approximations that have 1 - * ulp accuracy will automatically meet the monotonicity requirements. + * measured in terms of {@index ulp}s, {@index "units in + * the last place"}. For a given floating-point format, an + * {@linkplain #ulp(double) ulp} of a specific real number value is + * the distance between the two floating-point values bracketing that + * numerical value. When discussing the accuracy of a method as a + * whole rather than at a specific argument, the number of ulps cited + * is for the worst-case error at any argument. If a method always + * has an error less than 0.5 ulps, the method always returns the + * floating-point number nearest the exact result; such a method is + * correctly rounded. A {@index "correctly rounded"} + * method is generally the best a floating-point approximation can be; + * however, it is impractical for many floating-point methods to be + * correctly rounded. Instead, for the {@code Math} class, a larger + * error bound of 1 or 2 ulps is allowed for certain methods. + * Informally, with a 1 ulp error bound, when the exact result is a + * representable number, the exact result should be returned as the + * computed result; otherwise, either of the two floating-point values + * which bracket the exact result may be returned. For exact results + * large in magnitude, one of the endpoints of the bracket may be + * infinite. Besides accuracy at individual arguments, maintaining + * proper relations between the method at different arguments is also + * important. Therefore, most methods with more than 0.5 ulp errors + * are required to be {@index "semi-monotonic"}: whenever + * the mathematical function is non-decreasing, so is the + * floating-point approximation, likewise, whenever the mathematical + * function is non-increasing, so is the floating-point approximation. + * Not all approximations that have 1 ulp accuracy will automatically + * meet the monotonicity requirements. * *
* The platform uses signed two's complement integer arithmetic with - * int and long primitive types. The developer should choose - * the primitive type to ensure that arithmetic operations consistently - * produce correct results, which in some cases means the operations - * will not overflow the range of values of the computation. - * The best practice is to choose the primitive type and algorithm to avoid - * overflow. In cases where the size is {@code int} or {@code long} and - * overflow errors need to be detected, the methods whose names end with - * {@code Exact} throw an {@code ArithmeticException} when the results overflow. + * {@code int} and {@code long} primitive types. The developer should + * choose the primitive type to ensure that arithmetic operations + * consistently produce correct results, which in some cases means the + * operations will not overflow the range of values of the + * computation. The best practice is to choose the primitive type and + * algorithm to avoid overflow. In cases where the size is {@code int} + * or {@code long} and overflow errors need to be detected, the + * methods whose names end with {@code Exact} throw an {@code + * ArithmeticException} when the results overflow. * *