wren
wren copied to clipboard
Unnecessarily large bit pattern for QNAN?
Forgive me if I'm off base here... I was just reading wren_value.h and digesting the description of NaN-tagging. The description says that the 11 exponent bits plus the highest bit of the mantissa need to be set for a qNaN. (This seems to match https://en.wikipedia.org/wiki/Double-precision_floating-point_format.).
However, https://github.com/munificent/wren/blob/master/src/vm/wren_value.h#L538 says 0x7ffc000000000000, which I think is 13 set bits. Is there another reason why it can't be 0x7ff8...? i.e. do the two top bits of the mantissa need to be set for some reason?
(I don't think it matters too much either way as far as functionality though.)
Nice catch.
any number between 0x7ff8000...000 and 0x7fffff...fff is a quiet NaN (IIRC). Why Bob went with 0x7ffc0...000? only him can answer.
Was doing some homework on wren code, looking at double implementation on x86*. I found that Intel processors can produce "QNan Floating-Point Indefinte" values witch seems to be 0xfff8000...000. So to distiguish from those, infortunately it is required to consume an extra bit.
Bob explained it in detail in his book 😄 https://craftinginterpreters.com/optimization.html#nan-boxing