Hi Raffaello, Thanks for your execllent analysis. I agree with you now. And I'll close the optimization PR [1] tomorrow if there is no objections.
Thanks. Best regards, Jie [1] https://github.com/openjdk/jdk/pull/3404/ On 2021/4/12, 9:06 PM, "Raffaello Giulietti" <[email protected]> wrote: Hi Jie, I don't think that changing the spec of Math.pow() to be misaligned with IEEE 754 would be a wise option. IEEE is much more pervasive than Java. There are many aspects in IEEE that might be seen as questionable, but at least it is a widely adopted standard. AFAIU, the only reason you would like to "optimize" the special case of y = 0.5 in pow(x, y) to return sqrt(x) is for performance, more accuracy and some kind of consistency. But then, why not a special case for y = 0.25 as sqrt(sqrt(x))? And what about y = 0.75? Should this be translated to sqrt(sqrt(pow(x, 3)))? What about y = 1.0 / 3.0? Should this become cbrt(x)? And why not consider y = 2.0 / 3.0 in a special rule: cbrt(x * x)? You see, the special cases can quickly become unmanageable. Also, special rules would produce results which are "discontinuous" with nearby exponents, like y = 0.5000000000000001. That's probably why IEEE doesn't propose translation rules for finite numerical exponents that are not integers, except when x is a special value. Greetings Raffaello On 2021-04-12 13:44, jiefu(傅杰) wrote: > Hi Andrew H, Andrew D, and Raffaello, > > Thank you all for your kind reply and helpful comments. > > Now I got where the rules come from. > But I don't think the IEEE standars are reasonable to specify conflits rules. > Maybe, these computations should be open to be implementation dependent. > > (If it's possible) I really hope the special cases of Math.pow(x, 0.5) can be aligned with Math.sqrt(x) in Java. > We already allow some plausible behaviors to be different with the IEEE recommendations for some special cases, right? > And in that case, we can replace pow(x, 0.5) with sqrt(x) safely. > > Thanks. > Best regards, > Jie > > > On 2021/4/12, 6:40 PM, "Raffaello Giulietti" <[email protected]> wrote: > > Hi Jie, > > the behavior you report is the one specified by the standard IEEE 754. > Java follows this standard as closely as it can. > > The standard says that > * squareRoot(-0) = -0 > * squareRoot(-∞) = NaN > > Also, the standard has a long lists of special cases for pow(x, y), > among them: > * pow(±0, y) is +0 for finite y > 0 and not an odd integer > * pow(-∞, y) is +∞ for finite y > 0 and not an odd integer > > Thus, the conflicts you observe originate in following the standard, not > by special Java rules. > > Unfortunately, the IEEE standard does not explain the reasons for the > special rules. Some are obvious, some are not. > > > HTH > Raffaello > > > > Hi all, > > > > I found Math.pow(x, 0.5) and Math.sqrt(x) would compute different values as the following: > > ``` > > Math.pow(-0.0, 0.5) = 0.0 > > Math.sqrt(-0.0) = -0.0 > > > > Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity > > Math.sqrt(Double.NEGATIVE_INFINITY) = NaN > > ``` > > > > The reason is that both of pow and sqrt have special rules for these computations. > > For example, this rule [1] specifies Math.pow(-0.0, 0.5) must be 0.0. > > And this one [2] specifies Math.sqrt(-0.0) must be -0.0. > > And we do have rules for Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity and Math.sqrt(Double.NEGATIVE_INFINITY) = NaN too. > > > > I think most people will be confused by these rules because from the view of mathematics, Math.pow(x, 0.5) should be equal to Math.sqrt(x). > > > > So why Java creates conflict special rules for them? > > Is it possible to let Math.pow(-0.0, 0.5) = -0.0 and Math.pow(Double.NEGATIVE_INFINITY, 0.5) = NaN also be allowed? > > > > I came across this problem when I was trying to optimize pow(x, 0.5) with sqrt(x). > > If pow(x, 0.5)'s two special rules can be aligned with sqrt(x), then pow(x, 0.5)'s performance can be improved by 7x~14x [3]. > > > > Thanks. > > Best regards, > > Jie > > >
