Stream: beginners

Topic: NaN and reference equality

Martin Stewart (Feb 09 2022 at 21:52):

The discussion about reference equality in this topic https://roc.zulipchat.com/#narrow/stream/304641-ideas/topic/memoization.20builtin got me thinking about an edge case. In Elm, like Roc, the user isn't able to perform reference equality directly on two values. However in Elm there is a sneaky loop hole:

a = { field = 0/0 }
b = a == a --This is true
c = a == { field = 0/0 } --This is false

This happens because the floating point standard says that NaN isn't equal to itself. So if reference equality fails, checking the record fields also fails due to the NaN.

Is this possible in Roc? Presumably this isn't something that's desired but if you prevent it then I guess technically you aren't following the floating point standard? I don't know what implications this has but I figured it's worth bringing up.

Folkert de Vries (Feb 09 2022 at 21:55):

I think we want to roc_panic on 0 / 0 and similar math domain errors?

Folkert de Vries (Feb 09 2022 at 21:55):

similar to how we panic on overflow

Folkert de Vries (Feb 09 2022 at 21:56):

in practice a roc F64 should never be a NaN

Martin Stewart (Feb 09 2022 at 21:57):

Ah, I didn't think of that but I think that's the best choice!

Richard Feldman (Feb 09 2022 at 22:17):

in practice a roc F64 should never be a NaN

this is true today, although the more I think about it the more likely I think we are to end up wanting to support it for performance reasons

Martin Stewart (Feb 09 2022 at 22:32):

Maybe there could be an unsafe float type that doesn’t check for NaN or overflows and a safe float type that returns an unsafe float (or maybe Err) on any operations that can overflow or return NaN?

Last updated: Jul 05 2025 at 12:14 UTC