4 ms·
Part of it is not wasting so many bit patterns on valid NaN values. That is sort of free, I think. > Whereas floating point numbers are polluted with NaN value
by evdubs 4y ago
Part of it is not wasting so many bit patterns on valid NaN values. That is sort of free, I think.
> Whereas floating point numbers are polluted with NaN values, posits are cleansed of such unclean special values.
https://www.cs.cornell.edu/courses/cs6120/2019fa/blog/posits/ https://www.cs.cornell.edu/courses/cs6120/2019fa/blog/posits...
- js8 4y agoI think NaNs are pretty useful. I think we should have reserved 0x80000000 as a NaN value for integers.
- Aardwolf 4y agoOn signed integers, -0x80000000 returns 0x80000000 itself since there's no positive value opposite to this negative value, so 0x80000000 as NaN would make sense, but alternatively 0x80000000 as projective infinity would also make sense
- ljosifov 4y ago+1. I do that sometimes, have INT_NAN map to INT_MIN. It is of limited practical use without hardware support such that as in FLOAT_NAN, any operation involving it, results in NAN. Still - I find that improves my code readability, so small +ve gain imho.
- adgjlsfhk1 4y agoposits still have Near which is a single NaN like value. the problem with floats is that they have -0, -inf, inf and a bunch of NaN values. float16 for example wastes over 1000 of the 65000 numbers or can represent on non-finite numbers.
- IshKebab 4y agoThat's a really interesting idea. On the other hand it does add quite a lot of complexity to something that is quite simple. And it raises some awkward questions like how do you represent NaN for unsigned integers and if you don't then you have the awkward fact that there's one more unsigned than signed number. I can imagine an alternative timeline where it worked like that though.