You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "Paul King (Jira)" <ji...@apache.org> on 2021/03/12 03:17:00 UTC
[jira] [Updated] (GROOVY-9981) CLONE - println(-0.0f) does not
comply with IEEE754
[ https://issues.apache.org/jira/browse/GROOVY-9981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul King updated GROOVY-9981:
------------------------------
Description:
In GROOVY-9797 we fixed a bug where Groovy wasn't correctly writing the -0.0f constant when writing bytecode (symptoms as per quoted text). This issue is to fix documentation and provide helper methods for anyone relying on the previous behavior.
{quote}
IEEE754-2019 (which supersedes all previous floating point standards for decimal or binary floating point) states that an implementation *shall* (that means "is required to") preserve the sign on floating point numbers when it converts numbers to an "external decimal character sequence" (that means "prints them the way everyone does, unless you use special formatting characters I guess"), singling out the two zeros and the two infinities in particular for this treatment.
IEEE754-2019 does not say this for no reason. It's because conformant floating point implementations can print the float out and then later read it back into its original floating point bit-pattern. A close reading of IEEE754-1985 suggests this was always the intention, but this requirement was made unambiguously explicit for signed zeros as early as IEEE854-1987.
On all the versions of Apache Groovy's REPL that I was able to trivially easily test, println(-0.0f) does not output "-0.0", but outputs "0.0" instead. While I am aware that printf is also available in Groovy and can allow one to select formatting, this should probably be considered a bug, especially given that println in Java (OpenJDK 14) outputs "-0.0" and so do Kotlin, Scala, and Clojure with their relevant commands.
This bug suggests there are other errors relevant to IEEE754 compliance in relevant formatting and parsing code, so it is a good idea to do a more thorough audit as well.
{quote}
was:
In GROOVY-9797 we fixed a bug where Groovy wasn't correctly writing the 0.0f constant when writing bytecode (symptoms as per quoted text). This issue is to fix documentation and provide helper methods for anyone relying on the previous behavior.
{quote}
IEEE754-2019 (which supersedes all previous floating point standards for decimal or binary floating point) states that an implementation *shall* (that means "is required to") preserve the sign on floating point numbers when it converts numbers to an "external decimal character sequence" (that means "prints them the way everyone does, unless you use special formatting characters I guess"), singling out the two zeros and the two infinities in particular for this treatment.
IEEE754-2019 does not say this for no reason. It's because conformant floating point implementations can print the float out and then later read it back into its original floating point bit-pattern. A close reading of IEEE754-1985 suggests this was always the intention, but this requirement was made unambiguously explicit for signed zeros as early as IEEE854-1987.
On all the versions of Apache Groovy's REPL that I was able to trivially easily test, println(-0.0f) does not output "-0.0", but outputs "0.0" instead. While I am aware that printf is also available in Groovy and can allow one to select formatting, this should probably be considered a bug, especially given that println in Java (OpenJDK 14) outputs "-0.0" and so do Kotlin, Scala, and Clojure with their relevant commands.
This bug suggests there are other errors relevant to IEEE754 compliance in relevant formatting and parsing code, so it is a good idea to do a more thorough audit as well.
{quote}
> CLONE - println(-0.0f) does not comply with IEEE754
> ---------------------------------------------------
>
> Key: GROOVY-9981
> URL: https://issues.apache.org/jira/browse/GROOVY-9981
> Project: Groovy
> Issue Type: Bug
> Components: Groovysh
> Affects Versions: 2.5.7, 2.4.17, 2.5.13, 3.0.6
> Environment: Linux
> Reporter: Jubilee
> Assignee: Paul King
> Priority: Minor
> Labels: double, float
> Fix For: 4.0.0-alpha-3
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> In GROOVY-9797 we fixed a bug where Groovy wasn't correctly writing the -0.0f constant when writing bytecode (symptoms as per quoted text). This issue is to fix documentation and provide helper methods for anyone relying on the previous behavior.
> {quote}
> IEEE754-2019 (which supersedes all previous floating point standards for decimal or binary floating point) states that an implementation *shall* (that means "is required to") preserve the sign on floating point numbers when it converts numbers to an "external decimal character sequence" (that means "prints them the way everyone does, unless you use special formatting characters I guess"), singling out the two zeros and the two infinities in particular for this treatment.
> IEEE754-2019 does not say this for no reason. It's because conformant floating point implementations can print the float out and then later read it back into its original floating point bit-pattern. A close reading of IEEE754-1985 suggests this was always the intention, but this requirement was made unambiguously explicit for signed zeros as early as IEEE854-1987.
> On all the versions of Apache Groovy's REPL that I was able to trivially easily test, println(-0.0f) does not output "-0.0", but outputs "0.0" instead. While I am aware that printf is also available in Groovy and can allow one to select formatting, this should probably be considered a bug, especially given that println in Java (OpenJDK 14) outputs "-0.0" and so do Kotlin, Scala, and Clojure with their relevant commands.
> This bug suggests there are other errors relevant to IEEE754 compliance in relevant formatting and parsing code, so it is a good idea to do a more thorough audit as well.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)