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
Of course nothing for free, but the point is to trade things you don't need for things you do.
I also expect that chip area and power consumption for IEEE floating point has been optimized quite a bit more than for this novel number format, so there may be some efficiency left on the table on those particular metrics.
The posit is a compressed floating point encoding with a flexible data structure with a trade-off of precision (the number of bits after the dot) and magnitude (the absolute value).
It uses more hardware because the posit is decoded into a floating point larger than a equivalent IEEE754 with the same number of bits. So, the logic units needs to be larger.
Yes. Nothing for free.