8314489: Add javadoc index entries for java.lang.Math terms

Reviewed-by: alanb

Author: jddarcy

src/java.base/share/classes/java/lang/Math.java

@@ -55,44 +55,46 @@
  * <p>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 <i>ulps</i>, 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 <i>correctly
- * rounded</i>.  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
- * <i>semi-monotonic</i>: 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 <dfn>{@index ulp}s</dfn>, {@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
+ * <dfn>correctly rounded</dfn>.  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 <dfn>{@index "semi-monotonic"}</dfn>: 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.
  *
  * <p>
  * 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.
  *
  * <h2><a id=Ieee754RecommendedOps>IEEE 754 Recommended
  * Operations</a></h2>
@@ -119,7 +121,6 @@
  * @see <a href="https://standards.ieee.org/ieee/754/6210/">
  *      <cite>IEEE Standard for Floating-Point Arithmetic</cite></a>
  *
- * @author  Joseph D. Darcy
  * @since   1.0
  */