Joe,
Here are my comments.
1) Probably in lines StrictMath:1171, StrictMath:1220, Math:1487, Math:1593
you meant
{@code -0.0 * +0.0}
{@code -0.0f * +0.0f}
2) Lines Math:1508-1525 could be simpler:
====
double result = a * b + c;
return Double.isNaN(result) && Double.isFinite(a) && Double.isFinite(b)
? c : result;
====
JVM may use either double or double-extended-exponent value set for a *
b.
Values stored in the result variable might be different, but the value
returned by fusedMac(double,double.double) method will be the same.
For example a = 0x1p1023, b = 0x1p1023, c = Double.NEGATIVE_INFINITY;
a * b is either Double.POSITIVE_INFINITY or 0x1p2046
a * b + c is either Double.NaN or Double.NEGATIVE_INFINITY
result is either Double.NaN or Double.NEGATIVE_INFINITY
return value is Double.NEGATIVE_INFINITY in both cases.
3) As you say, this implementation favors code simplicity over speed.
There are five special cases in lines Math:1526-1530 .
Three of them (a==0.0, b==0.0, c==0.0) are essential because BigDecimal
can't handle signed zeroes.
The other two (a==1.0, b==1.0) are optimizations. BigDecimal handles
them correctly.
I think that the code would be simpler without the last two cases.
Otherwise, one may ask why similar special cases (a==-1.0, b==-1.0) are
not considered as well.
Best Regards.
