This is interesting but it's not obvious to me that this is an area where Go needs to lead. It would be painful if we added posits to the language and they didn't catch on.

I think the right first step is a third party package that implements them in a Go callable form, even though the normal operators would have to be implemented as methods.

Even apart from the risk of adding it to the language, as it stands, I'm not sure that the posit standard is a drop-in replacement for floating-point as the paper claims. The fact that there are no signed infinities will break calculations that depend on that property.

More importantly, the fact that the standard doesn't specify a NaN value means that errors like 0.0 / 0.0 have to be signaled separately. Errors cannot quietly propagate through calculations like with qNaNs, so in Go that means either panicking or returning an error.

I would definitely want to try a library implementation like Ian mentioned, since there is no rush to preemptively support a datatype even before the hardware catches up.

Posit does have a NaR (not a real number) value that represents IEEE NaN, 0/0, ±inf, etc.
There is a comprehensive analysis here, also comparing the two.

Another piece, for balance (not by the author of posit, but by a leading numerics group).

https://hal.inria.fr/hal-01959581v3/document

from the conclusion:

"When posits are better than floats of the same size, they provide one or two extra digits of accuracy [19]. When they are worse than floats, the degradation of accuracy can be arbitrarily large. This simple observation should prevent us from rushing to replace all the floats with posits."

True, that is a fundamental feature of posits. They provide better accuracy for typical numbers, and worse accuracy for very large/small magnitude numbers.

Posit does have a NaR (not a real number) value that represents IEEE NaN, 0/0, ±inf, etc.

Interesting. It seems Gustafson justifies the NaR by arguing that

As with nonstandard rounding modes, a need to distinguish underflow, overflow, and NaN is generally an indication that an application is still in development and not yet ready for production use.

I'm not sure how often this principle is respected in practice, but this and the lack of subnormals greatly simplifies arithmetic. However, this proposal should either be put on hold or declined, since we should first experiment outside of library before moving forward. Further discussion should probably be on a mailing list.

Why posits rather than, say, intervals or the more interval-like valids?

From IEEE floats to interval arithmetic is probably too much to swallow for general community, so posits are the intended replacement by its designers, I think.

Hrm. I'm not sure why they would expect two breaking ABI (and semantic) changes to be more acceptable than one change to the more desirable end state.

I didn't get what you mean, was it for another issue?

No, I mean that I don't see the point in adding posits and getting folks to migrate if there is something better — perhaps interval-based — just over the horizon.

Here authors describe the unum evolution, posits are the 3rd generation and their proposed replacement for IEEE 754.

There is no reason for Go to be an early adopter. Let's wait until there is a clear move toward posits before adding it to the language. Putting the issue on hold for now. In the meantime, a third party package would be an interesting idea.

http://www.johngustafson.net/pdfs/BeatingFloatingPoint.pdf

Pretty comprehensive read on the ins-and-outs of posits along with comparisons to IEEE-754.

I have a semi-performant posit library over at https://gitlab.com/amfiremage/gosit. This, of course, performs nowhere as close as hardware floating points from the standard library, but most operations are reasonably fast compared to rusts implementation of soft-posit. Only the basic bath operations (*,/,+,-,sqrt), floor, and round (but no ceil) are implemented. No 64 bit posits are supported, since some operations would require 128 bit ints.

Since people asked for a third-party library first, I thought I would link mine. It is fuzzed against softposit-rs, and even found some bugs in their implementation. As long as the application can do with these basic operators, anyone can test this out in their application. Just dont expect a performance improvement. Maybe when you are heavily band-width limited and you can use 32 bits instead of 64, but that's probably rare.

No, I mean that I don't see the point in adding posits and getting folks to migrate if there is something better — perhaps interval-based — just over the horizon.

Interval algorithmic is not fundamentally better, it is more expensive and takes more time. It can also often give you one single answer, so things like ordering, cant really be defined. And besides, if you have interval algorithmic, you need a format for the min/max. With valids this would be posits, you need posits to have valids. Not exposing them to the users is something I would be against.

From the framing of this issue it sounds to me that the question is not whether this change would be 'breaking' as some suggest. The issue suggests adding new types and not replacing floats (my understanding). I'd imagine any package with posit64 as an identifier would benefit greatly from a built-in. 🙂

Now that we have 'gosits' it is a good time to start playing around with them and test how they fare in action and keep a lookout for posit (or intervals, if that be the case) movements in the hw world.

Here is the new posit standard, one important simplification is es=2 always.