Uploaded image for project: 'Groovy'
  1. Groovy
  2. GROOVY-9981

CLONE - println(-0.0f) does not comply with IEEE754

Attach filesAttach ScreenshotVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments


    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 2.5.7, 2.4.17, 2.5.13, 3.0.6
    • Fix Version/s: 3.0.8, 4.0.0-alpha-3
    • Component/s: None
    • Labels:
    • Environment:


      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.

      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.


        Issue Links



            • Assignee:
              paulk Paul King
              workingjubilee Jubilee


              • Created:

                Time Tracking

                Original Estimate - 24h
                Remaining Estimate - 24h
                Time Spent - Not Specified
                Not Specified

                  Issue deployment