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

Reviewed-by: alanb

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

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