On Sat, 26 Feb 2022 04:55:08 GMT, Jatin Bhateja <jbhat...@openjdk.org> wrote:
>> Jatin Bhateja has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 8279508: Adding descriptive comments. > > As per SDM, if post conversion a floating point number is non-representable > in destination format e.g. a floating point value 3.4028235E10 post integer > conversion will overflow the value range of integer primitive type, hence a > -0.0 value or 0x80000000 is returned here. Similarly for +/- NaN and +/-Inf > post conversion value returns is -0.0. All these cases i.e. post conversion > non-representable floating point values and NaN/Inf values are handled in a > special manner where algorithm first performs an unordered comparison b/w > original source value and returns a 0 in case of NaN, this weeds out the NaN > case and for rest of the special values we check the MSB bit of the source > and either return an Integer.MAX_VALUE for +ve numbers or a Integer.MIN_VALUE > to adhere to the semantics of Math.round API. > > Existing tests were enhanced to cover various special cases (NaN/Inf/+ve/-ve > value/values which may be inexact after adding 0.5/ values which post > conversion overflow integer value range). @jatin-bhateja The patch looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094
