Re: ... replacement for 14.4 and C6.2 (interchange encodings)
Michel,
> In any case, we are only discussing *interchange* formats here. Each
> environment is still free to choose appropriate internal representations.
Yes. And it seems to me that it is easy to extract decoration when it is encoded
in payload. It is logical AND with a certain bit mask and possibly a shift.
Extraction of decoration from encodings of values 0.0 2.0 4.0 8.0 12.0
is either a conversion from floating-point to integer
or a manipulation with exponent and mantissa fields that is more complicated than the extraction from payload.
Maybe 16+0.0 16+2.0 16_4.0 16+8.0 16+12.0 is better as the decoration again can be
extracted by a logical AND.
Aestetically keeping in payload seems more natural to me,
but I have no experiense in implementation of compressed intervals.
-Dima
----- Original Message -----
From: mhack@xxxxxxx
To: stds-1788@xxxxxxxxxxxxxxxxx
Sent: Thursday, June 26, 2014 11:27:08 PM GMT +04:00 Abu Dhabi / Muscat
Subject: 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