|
Besides the special cases infinities and NaNs there are four points relevant to understand the encoding of decimal64.
-* 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<sup>8</sup> = 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.
-* The significands are not 'normalized' (the leading digit(s) are allowed to be "0"), and thus most values with less than 7 [[significant digits]] have multiple possible representations; 1000000 × 10<sup>-2</sup>=100000 × 10<sup>-1</sup>=10000 × 10<sup>0</sup>=1000 × 10<sup>1</sup> 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.
-* 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.
-* 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<sub>0</sub> '''.''' d<sub>−1</sub> d<sub>−2</sub> d<sub>−3</sub> d<sub>−4</sub> d<sub>−5</sub> d<sub>−6</sub> d<sub>−7</sub> d<sub>−8</sub> d<sub>−9</sub> d<sub>−10</sub> d<sub>−11</sub> d<sub>−12</sub> d<sub>−13</sub> d<sub>−14</sub> d<sub>−15</sub> (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<sub>6</sub> d<sub>5</sub> d<sub>4</sub> d<sub>3</sub> d<sub>2</sub> d<sub>1</sub> d<sub>0</sub> (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 all cases for decimal364, the value represented is
|
