On Fri, 7 Jun 2024 12:48:51 GMT, Raffaello Giulietti <rgiulie...@openjdk.org> wrote:
>> Joe Darcy has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Respond to review feedback. > > src/java.base/share/classes/java/lang/Double.java line 595: > >> 593: * This method corresponds to the convertToDecimalCharacter >> 594: * operation defined in IEEE 754. >> 595: * > > Does it? > > IEEE 754 `convertToDecimalCharacter` takes a 2nd argument, the > `conversionSpecification` which "specifies the precision and formatting of > the _decimalCharacterSequence_ result". There's no such flexibility here. > > Moreover, there seems to be no way to have a `conversionSpecification` that > ensures the "shortest decimal" semantics of this method. > > Finally, IEEE 754 requires to signal inexact exceptions. > > Suggestion: > > * This method vaguely corresponds to the convertToDecimalCharacter > > > The same holds for the other additional `@apiNote`s. > Does it? > > IEEE 754 `convertToDecimalCharacter` takes a 2nd argument, the > `conversionSpecification` which "specifies the precision and formatting of > the _decimalCharacterSequence_ result". There's no such flexibility here. > > Moreover, there seems to be no way to have a `conversionSpecification` that > ensures the "shortest decimal" semantics of this method. > > Finally, IEEE 754 requires to signal inexact exceptions. > > The same holds for the other additional `@apiNote`s. Thanks for the comments @rgiulietti . I've weakened the language for this method and added a javadoc to Formatter, which more closely aligns with the IEEE model of binary -> decimal conversion. For toHexString, the IEEE standard does state: "When converting to hexadecimal-significand character sequences in the absence of an explicit precision specification, enough hexadecimal characters shall be used to represent the binary floating-point number exactly." so the there isn't an exactly corresponding concern there. With the frame condition that the Java platform ignores the sticky flags, I think making the linkage to IEEE operations is still informative. Basically, (in many case) if you project down to the subset of IEEE 754 the Java platform supports, this Java method computes the same floating-point value as this IEEE operation, etc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19590#discussion_r1645286967
