1597 *
1598 * <p>Note that {@code fma(a, 1.0, c)} returns the same
1599 * result as ({@code a + c}). However,
1600 * {@code fma(a, b, +0.0)} does <em>not</em> always return the
1601 * same result as ({@code a * b}) since
1602 * {@code fma(-0.0, +0.0, +0.0)} is {@code +0.0} while
1603 * ({@code -0.0 * +0.0}) is {@code -0.0}; {@code fma(a, b, -0.0)} is
1604 * equivalent to ({@code a * b}) however.
1605 *
1606 * @apiNote This method corresponds to the fusedMultiplyAdd
1607 * operation defined in IEEE 754-2008.
1608 *
1609 * @param a a value
1610 * @param b a value
1611 * @param c a value
1612 *
1613 * @return (<i>a</i> × <i>b</i> + <i>c</i>)
1614 * computed, as if with unlimited range and precision, and rounded
1615 * once to the nearest {@code double} value
1616 */
1617 // @HotSpotIntrinsicCandidate
1618 public static double fma(double a, double b, double c) {
1619 /*
1620 * Infinity and NaN arithmetic is not quite the same with two
1621 * roundings as opposed to just one so the simple expression
1622 * "a * b + c" cannot always be used to compute the correct
1623 * result. With two roundings, the product can overflow and
1624 * if the addend is infinite, a spurious NaN can be produced
1625 * if the infinity from the overflow and the infinite addend
1626 * have opposite signs.
1627 */
1628
1629 // First, screen for and handle non-finite input values whose
1630 // arithmetic is not supported by BigDecimal.
1631 if (Double.isNaN(a) || Double.isNaN(b) || Double.isNaN(c)) {
1632 return Double.NaN;
1633 } else { // All inputs non-NaN
1634 boolean infiniteA = Double.isInfinite(a);
1635 boolean infiniteB = Double.isInfinite(b);
1636 boolean infiniteC = Double.isInfinite(c);
1637 double result;
1712 *
1713 * <p>Note that {@code fma(a, 1.0f, c)} returns the same
1714 * result as ({@code a + c}). However,
1715 * {@code fma(a, b, +0.0f)} does <em>not</em> always return the
1716 * same result as ({@code a * b}) since
1717 * {@code fma(-0.0f, +0.0f, +0.0f)} is {@code +0.0f} while
1718 * ({@code -0.0f * +0.0f}) is {@code -0.0f}; {@code fma(a, b, -0.0f)} is
1719 * equivalent to ({@code a * b}) however.
1720 *
1721 * @apiNote This method corresponds to the fusedMultiplyAdd
1722 * operation defined in IEEE 754-2008.
1723 *
1724 * @param a a value
1725 * @param b a value
1726 * @param c a value
1727 *
1728 * @return (<i>a</i> × <i>b</i> + <i>c</i>)
1729 * computed, as if with unlimited range and precision, and rounded
1730 * once to the nearest {@code float} value
1731 */
1732 // @HotSpotIntrinsicCandidate
1733 public static float fma(float a, float b, float c) {
1734 /*
1735 * Since the double format has more than twice the precision
1736 * of the float format, the multiply of a * b is exact in
1737 * double. The add of c to the product then incurs one
1738 * rounding error. Since the double format moreover has more
1739 * than (2p + 2) precision bits compared to the p bits of the
1740 * float format, the two roundings of (a * b + c), first to
1741 * the double format and then secondarily to the float format,
1742 * are equivalent to rounding the intermediate result directly
1743 * to the float format.
1744 *
1745 * In terms of strictfp vs default-fp concerns related to
1746 * overflow and underflow, since
1747 *
1748 * (Float.MAX_VALUE * Float.MAX_VALUE) << Double.MAX_VALUE
1749 * (Float.MIN_VALUE * Float.MIN_VALUE) >> Double.MIN_VALUE
1750 *
1751 * neither the multiply nor add will overflow or underflow in
1752 * double. Therefore, it is not necessary for this method to
|
1597 *
1598 * <p>Note that {@code fma(a, 1.0, c)} returns the same
1599 * result as ({@code a + c}). However,
1600 * {@code fma(a, b, +0.0)} does <em>not</em> always return the
1601 * same result as ({@code a * b}) since
1602 * {@code fma(-0.0, +0.0, +0.0)} is {@code +0.0} while
1603 * ({@code -0.0 * +0.0}) is {@code -0.0}; {@code fma(a, b, -0.0)} is
1604 * equivalent to ({@code a * b}) however.
1605 *
1606 * @apiNote This method corresponds to the fusedMultiplyAdd
1607 * operation defined in IEEE 754-2008.
1608 *
1609 * @param a a value
1610 * @param b a value
1611 * @param c a value
1612 *
1613 * @return (<i>a</i> × <i>b</i> + <i>c</i>)
1614 * computed, as if with unlimited range and precision, and rounded
1615 * once to the nearest {@code double} value
1616 */
1617 @HotSpotIntrinsicCandidate
1618 public static double fma(double a, double b, double c) {
1619 /*
1620 * Infinity and NaN arithmetic is not quite the same with two
1621 * roundings as opposed to just one so the simple expression
1622 * "a * b + c" cannot always be used to compute the correct
1623 * result. With two roundings, the product can overflow and
1624 * if the addend is infinite, a spurious NaN can be produced
1625 * if the infinity from the overflow and the infinite addend
1626 * have opposite signs.
1627 */
1628
1629 // First, screen for and handle non-finite input values whose
1630 // arithmetic is not supported by BigDecimal.
1631 if (Double.isNaN(a) || Double.isNaN(b) || Double.isNaN(c)) {
1632 return Double.NaN;
1633 } else { // All inputs non-NaN
1634 boolean infiniteA = Double.isInfinite(a);
1635 boolean infiniteB = Double.isInfinite(b);
1636 boolean infiniteC = Double.isInfinite(c);
1637 double result;
1712 *
1713 * <p>Note that {@code fma(a, 1.0f, c)} returns the same
1714 * result as ({@code a + c}). However,
1715 * {@code fma(a, b, +0.0f)} does <em>not</em> always return the
1716 * same result as ({@code a * b}) since
1717 * {@code fma(-0.0f, +0.0f, +0.0f)} is {@code +0.0f} while
1718 * ({@code -0.0f * +0.0f}) is {@code -0.0f}; {@code fma(a, b, -0.0f)} is
1719 * equivalent to ({@code a * b}) however.
1720 *
1721 * @apiNote This method corresponds to the fusedMultiplyAdd
1722 * operation defined in IEEE 754-2008.
1723 *
1724 * @param a a value
1725 * @param b a value
1726 * @param c a value
1727 *
1728 * @return (<i>a</i> × <i>b</i> + <i>c</i>)
1729 * computed, as if with unlimited range and precision, and rounded
1730 * once to the nearest {@code float} value
1731 */
1732 @HotSpotIntrinsicCandidate
1733 public static float fma(float a, float b, float c) {
1734 /*
1735 * Since the double format has more than twice the precision
1736 * of the float format, the multiply of a * b is exact in
1737 * double. The add of c to the product then incurs one
1738 * rounding error. Since the double format moreover has more
1739 * than (2p + 2) precision bits compared to the p bits of the
1740 * float format, the two roundings of (a * b + c), first to
1741 * the double format and then secondarily to the float format,
1742 * are equivalent to rounding the intermediate result directly
1743 * to the float format.
1744 *
1745 * In terms of strictfp vs default-fp concerns related to
1746 * overflow and underflow, since
1747 *
1748 * (Float.MAX_VALUE * Float.MAX_VALUE) << Double.MAX_VALUE
1749 * (Float.MIN_VALUE * Float.MIN_VALUE) >> Double.MIN_VALUE
1750 *
1751 * neither the multiply nor add will overflow or underflow in
1752 * double. Therefore, it is not necessary for this method to
|