Skip to content

NaN hashing/ordering is invalid #458

@asaites

Description

@asaites

The documentation for Expressions states often:

Note that when comparing Quil expressions, any embedded NaNs are treated as equal to other NaNs, not unequal, in contravention of the IEEE 754 spec [sic]1

The PartialEq implementation for Expression indeed considers two Numbers equal if, for example, their real and imaginary parts are both NaN; however, the Hash implementation hashes the bit patterns of those NaNs, so if they are different NaNs, for example, quiet vs signaling forms, they will hash to different values.

This is a problem because a valid Hash implementation requires that $x = y \implies Hash(x) = Hash(y)$.

We could instead use ordered_float or adjust our implementation to similarly treat all NaNs as a single specific value, though as those docs state, it has implications for interning: we'll lose semantic information about different NaN values.

Note that this is related to #457. We should fix this, and doing so will impact Expression simplification, and the solution may depend on how we want to simplify expressions involving floating point operations.

Footnotes

  1. To be pedantic, IEEE 754 specifies that NaN comparisons are unordered, not unequal.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions