Skip to content

Rust does not specify IEEE 754 rounding mode for signed zero #116339

Closed

Description

@orlp

Location

https://doc.rust-lang.org/std/primitive.f32.html

Summary

The Rust documentation on f32 states (emphasis mine):

When the number resulting from a primitive operation (addition, subtraction, multiplication, or division) on this type is not exactly representable as f32, it is rounded according to the roundTiesToEven direction defined in IEEE 754-2008.

However, this does not specify the behavior for -0.0f32 + 0.0f32. This value is exactly representable, the issue is in fact that it is representable in two ways. According to the IEEE754-2019 standard the behavior should be:

When the sum of two operands with opposite signs (or the difference of two operands with like signs) is exactly zero, the sign of that sum (or difference) shall be +0 under all rounding-direction attributes except roundTowardNegative; under that attribute, the sign of an exact zero sum (or difference) shall be -0.

In other words, the behavior depends on the rounding mode. We should specify that in this scenario we also follow the roundTiesToEven rounding mode, that is, the result of -0.0f32 + 0.0f32 should be 0.0f32.

Activity

  1. added
    A-docsArea: Documentation for any part of the project, including the compiler, standard library, and tools
    on Oct 2, 2023
  2. added
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Oct 2, 2023
  3. added
    T-langRelevant to the language team
    and removed
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Oct 2, 2023
  4. thomcc commented on Oct 2, 2023

    @thomcc
    Member

    IMO this is just a docs bug, where we were overly strict by specifying that the rounding mode only matters when the result "is not exactly representable". Patches should be welcome.

  5. orlp commented on Oct 2, 2023

    @orlp
    ContributorAuthor

    I agree, there is no reasonable world in which we'll use a different behavior for signed zero than what IEEE 754 prescribes for roundTiesToEven. What would better wording be?

  6. thomcc commented on Oct 2, 2023

    @thomcc
    Member

    Something along the lines of "is not exactly representable as a distinct f32" perhaps?

  7. orlp commented on Oct 2, 2023

    @orlp
    ContributorAuthor

    @thomcc I made a PR with an alternate wording I like. It simply drops any condition on rounding, simply stating we use the roundTiesToEven rounding mode, and clarifying what happens with sums.

    "The result is the representable value closest to the true value, if there is a unique closest representable value." also perfectly covers any result that doesn't need to be rounded, so no harm in dropping the condition.

  8. added a commit that references this issue on Oct 3, 2023
  9. added a commit that references this issue on Oct 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-docsArea: Documentation for any part of the project, including the compiler, standard library, and toolsT-langRelevant to the language team

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions