| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
However they also support an interchange medium at the binary level. One can't specify this for a "general" T assuming only what's in the Explicit/Implicit motion 19, but for each 754-conforming type we can easily define its interchange format (should it be "interchange type"?) as follows: - Nonempty xx=[xlo,xhi] is represented by bits(xlo) + bits(xhi). - Empty xx is represented, say, by bits(NaN) + bits(NaN). Here bits(x) is the bit-string of an F-number x (as described in the 754 standard), and + means concatenate. The resulting bit-string, call it interchange(xx), is to exist at a level above details like whether the machine is big- or little-endian, so we ignore those. One must decide various things such as: Is bits(x) canonicalized, e.g. is 0 always represented as +0? And are payloads of NaNs preserved on writing and reading? But basically the idea is simple.
This sounds good to me (I like Dan's suggestion, as well). Nate P.S. On a related tangent: Dan and Michel have noted in the past that there are currently no standards for propagating NaN payloads. So when it comes time for a motion to make some of these decisions about a standard interchange format, for Empty xx we may wish to consider a scheme something like this: bits(NaN) + bits(NaN) // No P1788-specific payload bits(NaN) + bits(payload) // P1788-specific payload bits(payload) + bits(NaN) // P1788-specific payload where bits(payload) is a bit-string reserved for any P1788-specific payload data (e.g., a bare decoration represented as an integer). The actual payloads of the NaNs can then be reserved for use according to existing (and possibly future) IEEE 754 standards. This way we potentially save ourselves from being at odds or cross-purposes with IEEE 754 implementations and standards.