[
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)
