decimal32 floating-point format

In computing, decimal32 is a decimal floating-point computer numbering format that occupies 4 bytes (32 bits) in computer memory. Like the binary16 and binary32 formats, it is intended for memory saving storage.

In contrast to the binaryxxx data formats the decimalxxx formats provide exact representation of decimal fractions, exact calculations with them and enable human common 'ties away from zero' rounding (in some range, to some precision, to some degree). In a trade-off for reduced performance. They are intended for applications where exact schoolhouse math is requested, such as financial and tax computations. (In short they avoid plenty of problems like 0.2 + 0.1 -> 0.30000000000000004 which happen with binary datatypes.)

decimal32 floating point is a relatively new decimal floating-point format, formally introduced in the 2008 version of IEEE 754 as well as with ISO/IEC/IEEE 60559:2011.

decimal32 supports 'normal' values which can have 7 digit precision from ±1.000000×10^⁻⁹⁵ up to ±9.999999×10^⁺⁹⁶, plus 'denormal' values with ramp-down relative precision down to ±1.×10^⁻¹⁰¹, zero, -/+infinities and NaN (Not a Number). The encoding in exponent and coefficient (other names are significand or - deprechated - mantissa) using a 'combination field', different coefficient encoding (BID or DPD) and different understanding of coefficient and 'exponent bias' is somewhat complex, see below.

(What is stored in bits can be understood as base to the power of 'stored value for the exponent minus bias of 95' times significand understood as 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 101' times significand understood as d₆ d₅ d₄ d₃ d₂ d₁ d₀ (note: no radix dot, significand integral), both lead to 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 corresponding binary format binary32 has an approximate range from denormal-min ±1×10^⁻⁴⁵, normal-min ±1.1754944×10^⁻³⁸ to max ±3.4028235×10^³⁸.

Because the significand is not normalized (the leading digit is allowed to be "0"), most values with less than 7 significant digits have multiple possible representations; 1000000 × 10^-2=100000 × 10^-1=10000 × 10⁰=1000 × 10¹ all have the value 10 000. These sets of representations for a same value are called cohorts, the different members can be used to denote how many digits of the value are known precisely. Zero has 192 possible representations (384 when both signed zeros are included).

Representation of decimal32 values

decimal32 values are represented in a 'not normalized' form and with combining some bits of the exponent with the leading bits of the coefficient in a 'combination field'.

Generic encoding

Sign	Combination	Trailing significand field
1 bit	11 bits	20 bits
s	ggggggggggg	tttttttttttttttttttt

That enables a little more 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.

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

In one representation method, based on binary integer decimal (BID), the significand is represented as binary coded positive integer.

The other, alternative, representation method is based on densely packed decimal (DPD) for most of the significand (except the most significant digit).

Both alternatives provide exactly the same range of representable numbers: 7 digits of significand and 3 × 2⁶ = 192 possible exponent values.

CAUTION!: transferring the binary representation between systems using different encodings will (mostly) be understood as valid decimal32 number, but with a different value, prefer transferring as 'triplets' of ASCII or integral representations of sign, exponent and significand.

The position of the relevant bits in the combination field is different between BID and DPD, but the functionality is similar, see tables below. This provides some bit saving because the 2 MSBs from the exponent only use three states, and the 4 MSBs of the significand stay within 0000 … 1001 (10 states). In total we have 3 × 10 = 30 possible values when combined in one encoding, which is representable in 5 bits (⁠$2^{5}=32$⁠).

In all cases, the value represented is

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

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

For ±Infinity, besides the sign bit, all the remaining bits are ignored (i.e., both the exponent and significand fields have no effect). For NaNs the sign bit has no meaning in the standard, and is ignored. Therefore, signed and unsigned NaNs are equivalent, even though some programs will show NaNs as signed. The bit g5 determines whether the NaN is quiet (0) or signaling (1). The bits of the significand are the NaN's payload and can hold user defined data (e.g., to distinguish how NaNs were generated). Like for normal significands, the payload of NaNs can be either in BID or DPD encoding.

Be aware that the bit numbering used here for e.g. g₁₀ … g₀  is in opposite direction than that used in the paper for the IEEE 754 standard g₀ … g₁₀.

BID Encoding

Combination Field												Exponent	Significand	Description
g10	g9	g8	g7	g6	g5	g4	g3	g2	g1	g0
combination field not! starting with '11', bits ab = 00, 01 or 10
a	b	c	d	m	m	m	m	e	f	g		abcdmmmm	(0)efgtttttttttttttttttttt	Finite number with small first digit of significand (0 … 7). This includes subnormal numbers where the leading significand digit is 0 and the exponent minimal.
combination field starting with '11', but not 1111, bits ab = 11, bits cd = 00, 01 or 10
1	1	c	d	m	m	m	m	e	f	g		cdmmmmef	100gtttttttttttttttttttt	Finite number with big first digit of significand (8 or 9).
combination field starting with '1111', bits abcd = 1111
1	1	1	1	0										±Infinity
1	1	1	1	1	0									quiet NaN
1	1	1	1	1	1									signaling NaN (with payload in significand)

The resulting exponent is a 8 bit binary integer where the leading bits are not '11', thus values 0 … 10111111_b = 191_d. The resulting significand could be a positive binary integer of 24 bits up to 1001 1111111111 1111111111_b = 10485759_d, but values above 10⁷ − 1 = 9999999 = 98967F₁₆ = 100110001001011001111111₂ are 'illegal' and have to be treated as zeroes. To obtain the individual decimal digits the significand has to be divided by 10 repeatedly.

DPD Encoding

Combination Field												Exponent	Significand	Description
g10	g9	g8	g7	g6	g5	g4	g3	g2	g1	g0
combination field not! starting with '11', bits ab = 00, 01 or 10
a	b	c	d	e	m	m	m	m	m	m		abmmmmmm	(0)cde tttttttttt tttttttttt	Finite number with small first digit of significand (0 … 7). This includes subnormal numbers where the leading significand digit is 0 and the exponent minimal.
combination field starting with '11', but not 1111, bits ab = 11, bits cd = 00, 01 or 10
1	1	c	d	e	m	m	m	m	m	m		cdmmmmmm	100e tttttttttt tttttttttt	Finite number with big first digit of significand (8 or 9).
combination field starting with '1111', bits abcd = 1111
1	1	1	1	0										±Infinity
1	1	1	1	1	0									quiet NaN
1	1	1	1	1	1									signaling NaN (with payload in significand)

The resulting exponent is a 8 bit binary integer where the leading bits are not '11', thus values 0 … 10111111_b = 191_d. The significand's leading decimal digit forms from the (0)cde or 100e bits as binary integer. To obtain the trailing significand decimal digits the declet fields 'tttttttttt' have to be decoded according to the DPD rules (see below). The full decimal significand is then obtained by concatenating the leading and trailing decimal digits.

The 10-bit DPD to 3-digit BCD transcoding for the declets is given by the following table. b₉ … b₀ are the bits of the DPD, and d₂ … d₀ are the three BCD digits. Be aware that the bit numbering used here for e.g. b₉ … b₀ is in opposite direction than that used in the paper for the IEEE 754 standard b₀ … b₉, add. the decimal digits are numbered 0-base here while in opposite direction and 1-based in the IEEE 754 paper. The bits on white background are not counting for the value, but signal how to understand / shift the other bits. The concept is to denote which digits are small (0 … 7) and encoded in three bits, and which are not, then calculated from a prefix of '100', and one bit deciding if 8 or 9.

Densely packed decimal encoding rules

DPD encoded value												Decimal digits
Code space (1024 states)	b9	b8	b7	b6	b5	b4	b3	b2	b1	b0		d2	d1	d0	Values encoded	Description	Occurrences (1000 states)
50.0% (512 states)	a	b	c	d	e	f	0	g	h	i		0abc	0def	0ghi	(0–7) (0–7) (0–7)	3 small digits	51.2% (512 states)
37.5% (384 states)	a	b	c	d	e	f	1	0	0	i		0abc	0def	100i	(0–7) (0–7) (8–9)	2 small digits, 1 large digit	38.4% (384 states)
	a	b	c	g	h	f	1	0	1	i		0abc	100f	0ghi	(0–7) (8–9) (0–7)
	g	h	c	d	e	f	1	1	0	i		100c	0def	0ghi	(8–9) (0–7) (0–7)
9.375% (96 states)	g	h	c	0	0	f	1	1	1	i		100c	100f	0ghi	(8–9) (8–9) (0–7)	1 small digit, 2 large digits	9.6% (96 states)
	d	e	c	0	1	f	1	1	1	i		100c	0def	100i	(8–9) (0–7) (8–9)
	a	b	c	1	0	f	1	1	1	i		0abc	100f	100i	(0–7) (8–9) (8–9)
3.125% (32 states, 8 used)	x	x	c	1	1	f	1	1	1	i		100c	100f	100i	(8–9) (8–9) (8–9)	3 large digits, b9, b8: don't care	0.8% (8 states)

The 8 decimal values whose digits are all 8s or 9s have four codings each. The bits marked x in the table above are ignored on input, but will always be 0 in computed results. (The 8 × 3 = 24 non-standard encodings fill in the gap between 10³ = 1000 and 2¹⁰ = 1024.)

Benefit of this encoding is access to individual digits by de- / encoding only 10 bits, disadvantage is that some simple functions like sort and compare, very frequently used in coding, do not work on the bit pattern but require decoding to decimal digits (and evtl. re-encode to binary integers) first.

Before you ask: An alternate encoding as BCD or BID, 10 bits declets encoding 0_d ... 1023_d and simply using only the range from 0 to 999 would provide the same functionality, direct access to digits by de- / encoding 10 bits, with near zero performance penalty in modern systems, but the 'Sudoku encoding' shown above was chosen in history, may provide better performance in hardware implementations, and now 'is as it is'.

See also

• Scientific notation