wren icon indicating copy to clipboard operation
wren copied to clipboard

Unnecessarily large bit pattern for QNAN?

Open sgraham opened this issue 7 years ago • 4 comments

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.)

sgraham avatar Jun 25 '18 16:06 sgraham

Nice catch.

mhermier avatar Jun 29 '18 10:06 mhermier

any number between 0x7ff8000...000 and 0x7fffff...fff is a quiet NaN (IIRC). Why Bob went with 0x7ffc0...000? only him can answer.

minirop avatar Jun 29 '18 17:06 minirop

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.

mhermier avatar Oct 08 '18 07:10 mhermier

Bob explained it in detail in his book 😄 https://craftinginterpreters.com/optimization.html#nan-boxing

sfcgeorge avatar Sep 18 '21 16:09 sfcgeorge