Decimal64 floating-point format: Difference between revisions

Revision as of 03:34, 17 December 2024

Revision as of 20:08, 18 December 2024

Line 13:

Decimal64 supports 'normal' values that can have 16 digit precision from {{gaps|±1.000|000|000|000|000|e=-383}} to {{gaps|±9.999|999|999|999|999|e=384}}, plus 'denormal' values with ramp-down relative precision down to ±1 × 10⁻³⁹⁸, [[signed zero]]s, signed infinities and [[NaN]] (Not a Number).

The binary format of the same bit-size supports a range from denormal-min {{gaps|±5|||||e=-324|}}, over normal-min with full 53-bit precision {{gaps|±2.225|073|858|507|201|e=-308|4}} to max {{gaps|±1.797|693|134|862|315|e=+308|7}}.

== Representation / encoding of decimal64 values ==

decimal64 values are represented in a 'not normalized' near to 'scientific format', with combining some bits of the exponent with the leading bits of the significand in a 'combination field'.

Line 26:

|}

Besides the special cases infinities and NaNs there are four points relevant to understand the encoding of decimal64.

IEEE 754 allows two alternative encodings for decimal64 values. The standard does not specify how to signify which representation is used, for instance in a situation where decimal64 values are communicated between systems:

- BID vs. DPD encoding, '''B'''inary '''I'''nteger '''D'''ecimal using a positive [[binary integer decimal]] for the significand, software centric and designed by Intel(r), vs. '''D'''ensely '''P'''acked '''D'''ecimal based on [[densely packed decimal]] encoding for all except the first digit of the significand, hardware centric and promoted by IBM(r), differences see below. Both alternatives provide exactly the same range of representable numbers: 16 digits of significand and {{math|size=100%|1=3 × 2⁸ = 768}} possible exponent values. IEEE 754 allows these two different encodings, without a concept to denote which is used, for instance in a situation where decimal64 values are communicated between systems. CAUTION!: Be aware that transferring binary data between systems using different encodings will mostly produce valid decimal64 numbers, '''but with different value'''. Prefer data exchange in íntegral or ASCII 'triplets' for sign, exponent and significand.

* In the [[#Binary integer significand field|binary encoding]], the 16-digit significand is represented as a binary coded positive integer, based on [[binary integer decimal]] (BID).

* In the [[#Densely packed decimal significand field|decimal encoding]], the 16-digit significand is represented as a decimal coded positive integer, based on [[densely packed decimal]] (DPD) with 5 groups of 3 digits (except the most significant digit encoded specially) are each represented in declets (10-bit sequences). This is pretty efficient, because 2¹⁰ = 1024, is only little more than needed to still contain all numbers from 0 to 999.

Because- theThe significandsignificands forare not 'normalized' (the [[IEEEleading 754]]digit(s) decimalare formatsallowed isto notbe normalized"0"), and thus most values with less than 167 [[significant digits]] have multiple possible representations; 1000000 × 10^-2=100000 × 10^-1=10000 × 10⁰=1000 × 10¹ all have the value 10000. These sets of representations for a same value are called [[Cohort (floating point)|cohorts]]'','' the different members can be used to denote how many digits of the value are known precisely.

Both alternatives provide exactly the same set of representable numbers: 16 digits of significand and {{math|size=100%|1=3 × 2⁸ = 768}} possible decimal exponent values. (All the possible decimal exponent values storable in a [[binary64]] number are representable in decimal64, and most bits of the significand of a binary64 are stored keeping roughly the same number of decimal digits in the significand.)

- The encodings combine two bits of the exponent with the leading 3 to 4 bits of the significand in a 'combination field', different for 'big' vs. 'small' significands. That enables bigger precision and range, in trade-off that some simple functions like sort and compare, very frequently used in coding, do not work on the bit pattern but require computations to extract exponent and significand and then try to obtain an exponent aligned representation. This effort is partly balanced by saving the effort for normalization, but contributes to the slower performance of the decimal datatypes. Beware: BID and DPD use different bits of the combination field for that, see below.

In both cases, the most significant 4 bits of the significand (which actually only have 10 possible values) are combined with two bits of the exponent (3 possible values) to use 30 of the 32 possible values of a 5-bit field. The remaining combinations encode [[infinity|infinities]] and [[NaN]]s. BID and DPD use different bits of the combination field for that.

- Different understanding of significand as integer or fraction, and acc. different bias to apply for the exponent (for decimal64 what is stored in bits can be decoded as base to the power of 'stored value for the exponent minus '''bias of 383'''<nowiki/>' times significand understood as d₀ '''.''' d₋₁ d₋₂ d₋₃ d₋₄ d₋₅ d₋₆ d₋₇ d₋₈ d₋₉ d₋₁₀ d₋₁₁ d₋₁₂ d₋₁₃ d₋₁₄ d₋₁₅ (note: radix dot after first digit, significand '''fractional'''), or base to the power of 'stored value for the exponent minus '''bias of 398'''<nowiki/>' times significand understood as d15 d14 d13 d12 d11 d10 d9 d8 d7 d₆ d₅ d₄ d₃ d₂ d₁ d₀ (note: no radix dot, significand '''integral'''), both produce the same result [2019 version of IEEE 754 in clause 3.3, page 18]. For decimal datatypes the second view is more common, while for binary datatypes the first, the biases are different for each datatype.)

In the cases of Infinity and NaN, all other bits of the encoding are ignored. Thus, it is possible to initialize an array to Infinities or NaNs by filling it with a single byte value.

In all cases for decimal364, the value represented is

: (−1)^''sign'' × 10^{''exponent''−'''398'''} × ''significand'', with the ''significand'' understood as positive integer.

Alternatively it can be understood as (−1)^''sign'' × 10^{''exponent''−'''383'''} × ''significand'' with the ''significand'' digits understood as d₀ '''.''' d₋₁ d₋₂ d₋₃ d₋₄ d₋₅ d_{−6 ...}, note the radix dot making it a fraction.

decimal64 is superpower to binary64 in range, and head to head in precision, dec64 all normal values 16-digit, while bin64 alternates between 'not fully 16' and about 16.5 decimal digits ( 17 digits with gaps ).

Because the significand for the [[IEEE 754]] decimal formats is not normalized, most values with less than 16 [[significant digits]] have multiple possible representations; 1000000 × 10^-2=100000 × 10^-1=10000 × 10⁰=1000 × 10¹ all have the value 10000. These sets of representations for a same value are called [[Cohort (floating point)|cohorts]], the different members can be used to denote how many digits of the value are known precisely.

=== BID encoding ===

Line 180 ⟶ 185:

== Side effects, more info ==

DPD encoding is pretty efficient, not wasting more than about 2.4 percent of space vs. BID, because the 2¹⁰ = 1024 possible values in 10 bit is only little more than what is used to encode all numbers from 0 to 999.

Zero has 768 possible representations (1536 accounting signed zeroes, in two different cohorts), (even many more if you account the 'illegal' significands which have to be treated as zeroes).

The gain in range and precision by the 'combination encoding' evolves because the taken 2 bits from the exponent only use three of four possible states, and the 4 MSBs of the significand stay within 0000&nbsp;…&nbsp;1001 (10 of 16 possible states). In total that is {{math|1=3&nbsp;×&nbsp;10&nbsp;=&nbsp;30}} possible values when combined in one encoding, which is representable in 5 instead of 6 bits ({{tmath|1=2^5=32}}).

In the cases of Infinity and NaN, all other bits of the encoding are ignored. Thus, it is possible to initialize an array to Infinities or NaNs by filling it with a single byte value.

== See also ==