Re: ... replacement for 14.4 and C6.2 (interchange encodings)
On Thu, 26 Jun 2014 11:58:25 -0700 (PDT), Dmitry Nadezhin replied to me:
> > Also, in the paragraph "Applications exchanging data...", line 5:
> > merely requires the parameters -> merely requires that the parameters
>
> The full text says
>
> The standard merely requires the parameters of the octets-encoding
> be communicated
>
> Is this a bug or a differnce between Britain English and American English?
> Is it necessary to change the form of "be" in your wording?
I just added the word "that". The rest of the sentence was fine.
So it should be:
The standard merely requires that the parameters of the octet-encoding
be communicated
(Note that there was a left-over "octets-encoding" in the quoted text.
Let's make sure ALL instances have been corrected.)
> > several possibilities for encoding decorations, perhaps as NaN payloads,
> > or as small FP integers in one bound with a generic NaN in the other (to
> > avoid the many portability issues with NaN payloads).
>
> What are the portability issues ?
There are no standard ways for setting or extracting NaN payloads in most
environments. Although decimal-format NaN payloads are fully specified in
754-2008 (as small integers, i.e. small enough not to be beheaded by format
conversions to a narrower DFP type), there is no agreement on how a NaN
payload should be converted between DFP and BFP types. IBM's conversion
instructions and library routines treat the bit-reversed BFP trailing
significand (the fraction field, in the "unit" view) as a binary encoding
of a small integer, because that permits lossless conversion between all
supported decimal and binary formats, but (a) this is typically only
accessible to assembly-language programmers, and (b) other vendors may
use different rules. It's one of the issues that 754-2008 left unresolved.
(It would have been easy to define operations getNaNcode() and setNaNcode(),
but that realisation came too late for 754-2008.)
> It seems to me that program will get an exception with signalled NaNs
> and then explore encodings as bit string to extract decoration values.
Use of SNaNs is not the issue, but payload extraction is. Besides, it
might be better to use isNaN() than to rely on SNaN traps, though that
depends on the application, and on the frequency of exceptions.
That's why I propose to encode the decoration as a floating-point integer
and use a NaN in the other bound to discriminate between decorations and
intervals in a compressed-interval type. (One would of course have to
be careful with functions like sup() that might look at only one bound.)
In any case, we are only discussing *interchange* formats here. Each
environment is still free to choose appropriate internal representations.
Michel.
---Sent: 2014-06-26 19:25:39 UTC