For low precision applications posits may be a good choice, sometimes the best.
However it remains to be demonstrated that for high precisions they can be implemented in hardware with similar cost and speed as traditional floating-point numbers.
Regarding the actual advantages of posits, the papers of Gustafson et al. do not inspire much confidence, because besides some correct arguments about genuine advantages of posits, the papers are also full of BS claims, e.g. the claim that posits have the advantage of not generating NaNs.
They do not generate NaNs, because they generate an exception, which is exactly what the IEEE floats also do when you enable trap-on-undefined-operation.
There are also other very dubious claims. While it is very likely that for low precisions posits should be superior and that they might have been a much better alternative to the proliferation of various 16-bit FP formats for machine learning, I have yet to see a single example with posits behaving better than traditional FP formats at high precisions.
For low precisions, there is also the alternative of logarithmic numbers, which allow very fast arithmetic operations but which require look-up tables for addition and subtraction. It is not clear in which applications posits are preferable and in which applications logarithmic numbers are preferable.
This is not true. You base your whole comment on the notion that posits are only good for low precision? This is not correct, for instance 32-bit posits outperform 64-bit floats.
> e.g. the claim that posits have the advantage of not generating Nans. They do not generate NaNs, because they generate an exception
This is incorrect also. There are no exceptions in the posit proposal! The point is that e.g. a division by zero is simply a bug in the code, like violating any other ordinary invariant/precondition in ordinary code. If you want exceptions, turn on debugging in your compiler like you would turn on bounds checks on array access for instance. It's silly to require always-on debug assertions and maximum performance at the same time, which is what IEEE floats attempt and fail at.
Regarding NaN, the advantage in posits is that there is only one such value (unsigned infinity), rather than the quadrillions of NaN bit patterns in IEEE floats.
> I have yet to see a single example with posits behaving better than traditional FP formats at high precisions.
Again, then you cannot have read the posit proposal thoroughly x) they show that 32-bit floats outperform 64-bit floats in precision, sacrificing only some dynamic range which is useless anyway.
Consider now that most HPC applications nowadays are I/O bound... switching to 32-bit posits increases precision and slashes memory requirements by half. It's immense.
Al 32-bit formats have the same number of points that are distributed over the real numbers, partitioning them in intervals.
The difference in the possible numeric formats is only in the position of the points, so the number of intervals is identical. When for a numeric format the intervals in a certain area are smaller, i.e. the precision is better, that means that in another area the intervals must be larger, so the precision must be worse. Which areas are more important depends on the problem that must be solved.
The posits are just floating-point numbers where the partitioning between the logarithmic part (the exponent) and the linear part (the fraction) is not fixed, but variable.
The posits close to 1 have more fraction bits, while the posits closer to 0 and to infinities have more exponent bits and less fraction bits.
For certain problems 32-bit posits can outperform 32-bit IEEE floats, but 32-bit posits cannot outperform any 64-bit numeric format, because the 64-bit format has billions times more intervals so a 32-bit format does not have any chance of approximating better a number.
Posits can outperform standard floats only at low precision, because in the formats with few bits there are not enough bits to reserve for the exponent, so the exponent range is small, which makes overflows and underflows very likely.
Posits can have a much larger exponent range, while maintaining a good precision close to 1, paying their extended exponent range with reduced precision towards 0 and infinities, i.e. posits have a gradual underflow and overflow, which are more gradual than the IEEE gradual underflow.
At double precision or higher precisions, the IEEE floats have enough exponent range that underflows and overflows become very unlikely, so posits no longer have any advantage.
The standard floating-point numbers have an almost constant relative approximation error over their exponent range.
For most serious numerical work this is the approximation property that is desired. Posits have a variable relative approximation error that becomes worse and worse for small and large numbers. This is normally undesirable. Complex physical models always have both very small numbers and very large numbers that must be approximated well, even better than the numbers close to 1 that are preferred by posits.
Nevertheless for small floating-point numbers, e.g. 16-bit FP, avoiding overflows and underflows becomes more important than the loss of precision at exponent range extremities, so posits are better.
32-bit floats are around the threshold where posits transition from being better to being worse that standard FP numbers.
Depending on the problem, 32-bit floats or 32-bit posits may be better. On the other hand, I have never seen any problem where 64-bit posits, with their worse relative errors, could be better than IEEE double precision.
Imagine rust is being built and you reply
> Many things are possible in our imagination. I'm grateful in my actual world we have working BCPL.
:^)
