That'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.
+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.
posits 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.
On 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
> 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...