Go: Proposal: Go 2: Add Posit data type

[jfcg]

Posits are gaining traction as a replacement and clean improvement over IEEE 754. They offer reasonable dynamic ranges with better accuracy / energy efficiency / speed on many applications. They will probably replace IEEE floats in 5 to 10 years in cpus / gpus / tpus. They have an official standard.

Adding (experimental) support for posits will position Go 2 in a better place for developers' consideration who want to get better results out of their mathematical calculations in AI, ML, HPC, weather forecasting, astrophysics etc. areas in addition to typical backend programming that Go is already good at. This will possibly enable Go's penetration into scientific computing.

At the moment there is no hw architecture that supports posits, but there are many sw and fpga implementations. Initially it could start like soft-floats. As hw support becomes available, people will reap the benefits. Most floating-point code is readily convertable to posits: just rename data types.

Adding posits is non-trivial and a BIG step. It has to be done incrementally. Also there will possibly be a transition period where hw platforms will have IEEE floats and / or posits.

These are the (incomplete) steps of this proposal:

• add posit8, posit16, posit32, posit64 data types as per the standard
• add conversions from/to other data types
• add "printing/scanning posits" functionality to fmt library
• add math/posit standard library with standard Sine/Tan etc. (posit32)
• add cxposit32, cxposit64, cxposit128 complex number data types
• add math/cmplx/cxposit standard library (cxposit64)

There is a lot to do, so when hw support arrives, Go 2 will be ready to deliver ;)

[ianlancetaylor]

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.

[smasher164]

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.

[jfcg]

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.

[matt2909]

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."

[jfcg]

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

[smasher164]

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.

[bcmills]

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

[jfcg]

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.

[bcmills]

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.

[jfcg]

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

[bcmills]

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.

[jfcg]

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

[ianlancetaylor]

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.