Showing content from https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/payload-functions.txt below:
Date: Mon, 12 Feb 2018 09:25:46 -0500 From: Michel Hack Subject: Background discussion for the new Payload functions The notion of NaN payload has been around for a long time, and some applications have (in platform-bounded contexts) taken advantage of the platform's NaN-propagation rules to transmit information (so-called NaN-boxing); indeed, at one point IEEE 1788 compressed-interval encoding considered doing this (this was abandoned because one could not rely on anything with respect to NaN propagation). Some platforms encode tracking information in NaN payloads. Access to NaN payload was however limited to bit-twiddling (e.g. use of unions or overlays). When IEEE 754-2008 introduced decimal formats (DFP), NaNs were specified in complete detail, with the payload defined to be an integer with p-1 digits for a format of precision p. Meanwhile, C did define payload access functions that treated the payload as a floating-point integer in the same format as the NaN being accessed, which makes sense since the available precision exceeds that of what can be encoded in a payload by at least one bit. This led naturally to defining the 754-2019 payload access functions as homogeneous quiet computational operations (to avoid raising exceptions), in a manner that is compatible with the C definition by giving a full specification to cover the cases that C left undefined. The purpose of these functions is NOT cross-platform portability -- it is only to provide generic means to express intent. It is true that the standard says very little about binary floating-point (BFP) payloads, simply because in 2005 it had to accommodate 20 years of uncoordinated implementations and in fact few exploitations. About the only means of communicating anything about NaN payloads was through string conversions, and support for that also took a long time to emerge. In those strings the payload appears as an unsigned decimal integer. With DFP the working group started from scratch and could thus give a complete specification (or two -- but effectively they agree), and if we only dealt with DFP, getPayload and setPayload would be completely non-controversial. The new payload functions treat payloads logically the same way regardless of radix and make it clear that, except for decimal interchange formats, whatever mapping is implied is simply defined by the implementation -- end of story. Any honest particular implementation would document what it does, and what (if any) restrictions apply. One aspect that may need a bit of context is the asymmetry between getPayload and setPayload: the former may return a value that is deemed "inadmissible" for the latter (leading to a non-NaN result of 0). This is to allow platforms that use platform-generated NaNs to convey diagnostic information to avoid disturbing that. What's annoying about this is the fact that there is no easy way for an application to know what the range of admissible payloads is -- it has to rely on the platform's documentation. However, given the general cross-platform uncertainties about NaN propagation, this limitation should be tolerable. Any extensive exploitation of these functions will always be platform-dependent. But that does not diminish the advantage of having a standard way to write the program.
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4