Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposal: Go 2: Add Posit data type #33205
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:
There is a lot to do, so when hw support arrives, Go 2 will be ready to deliver ;)
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
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.
Another piece, for balance (not by the author of posit, but by a leading numerics group).
from the conclusion:
"When posits are better than floats of the same size, they provide one or two extra digits of accuracy . 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."
Interesting. It seems Gustafson justifies the NaR by arguing that
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.