Article URL: https://sebsite.pw/w/20260709-nan.html Comments URL: https://news.ycombinator.com/item?id=48903701 Points: 8 # Comments: 5

IEEE-754 NaN is weird. and because of that, it's often accidentally left unaccounted for. i found two instances of this leaking into programming language design. that is, the semantics of these languages hold implicit assumptions which break with NaN. as an optimization, when comparing lists for equality, elements are first compared by identity. they're only checked for equality if their identities are unequal. in general, it's assumed that an object will always compare equal to itself. this is explicitly noted in the python 3 reference manual: User-defined classes that customize their comparison behavior should follow some consistency rules, if possible: this isn't true for NaN. and that's fine, but because the assumption does hold for pretty much everything else, design choices are made which leave NaN unaccounted for (or at least, give NaN very weird behavior). to be clear, i'm not necessarily saying that python's behavior here is wrong, or that this optimization is bad because NaN behaves weirdly. but i think it's at least worth pointing out. the way this is supposed to work is that i starts with the initial value (here that's 1), and each iteration it increments by the step (optional third operand; defaults to 1), until the new value is greater than the limit (10), at which point the loop terminates. so this loop iterates 10 times, from 1 to 10 (inclusive). so what happens when NaN (0/0) is thrown into the mix? here's the behavior in the reference implementation (puc-rio lua):