Talk:Decimal32 floating-point format

What implementations are there of this format?

Concerns about this page

The IEEE 754 standard goes to great lengths to separate the representation of the valid set of numbers in (say) decimal32 from the encoding of interchange formats (a particular representation in a string of binary bits), yet this article seems to muddle the concepts. Might it be better to follow the way it is described in the standard (clause 3)?

There are other problems too: 0.000000×10^−95 to 9.999999×10^96 is not the full range of the format in any sense; also (to be pedantic) the name of the format, in the standard, starts with a lower-case d.

mfc (talk) 17:41, 30 December 2009 (UTC)

Combination field bit naming

Why are the bits of the combination field named m0 to m5? They are not a mantissa, c0 to c5 would make more sense. — Preceding unsigned comment added by 88.219.179.99 (talk) 10:29, 14 March 2021 (UTC)

Inconsistent/erroneous claims

"Encoding of the Combination Field" (1) contradicts what is said later under "Binary integer significand field" (2).

In (1) some bits are said to be part of the significand, that are said to be part of the exponent in (2). But decoded bits can only be part of the exponent or the significand.

A simple example: From "Encoding of the Combination Field" (1)

m4 	m3 	m2 	m1 	m0 	Exponent 	Significand
0 	0 	a 	b 	c 	00 	        0abc

From "Binary integer significand field" (2)

s 00eeeeee   (0)ttt tttttttttt tttttttttt

Since the combination field is preceded by a sign bit, (1) can be rewritten to:

s m4 m3 m2 m1 m0

Comparing the last two fixed-width font lines it must hold that:

m4 = 0, m3 = 0, m2 = e5, m1 = e4, m0 = e3

But from (1) we know that:

m2 = a, m1 = b, m0 = c

Which means:

m2 = e5 but also m2 = a

m1 = e4 but also m1 = b

m0 = e3 but also m0 = c

In other words m2, m1, m0 are said to be part of the significand in (1) but also part of the exponent in (2). This obviously cannot be true.

Edit: When you compare the "Densely packed decimal significand field" section with ""Encoding of the Combination Field" (1)" things start to make sense:

00 TTT (00)eeeeee (0TTT)[tttttttttt][tttttttttt]

indeed matches with

m4 	m3 	m2 	m1 	m0 	Exponent 	Significand
0 	0 	a 	b 	c 	00 	        0abc

In summary, the statement "In both cases, the most significant 4 bits of the significand (which actually only have 10 possible values) are combined with the most significant 2 bits of the exponent (3 possible values) to use 30 (=10*3) of the 32 possible values of a 5-bit field called the combination field." must be wrong! It is only true for the "Densely packed decimal significand field" encoding!

Edit: Fixed the inconsistences in the introduction.88.219.179.99 (talk) 18:13, 14 March 2021 (UTC)

— Preceding unsigned comment added by 88.219.179.99 (talk) 12:24, 14 March 2021 (UTC)

Whole article needs a revision

The article is inconsistent and the introduction inaccurate (see the section above, but there is more). Comparing with the IEEE standard makes this clear. The decimal64 and decimal128 articles have the same issue.

A major rewrite would be necessary. — Preceding unsigned comment added by 88.219.179.99 (talk) 13:05, 14 March 2021 (UTC)

 Edit: Large reformulation and rework of the article to clarify important parts  — Preceding unsigned comment added by 88.219.179.99 (talk) 18:11, 14 March 2021 (UTC) 

Missing descriptions

It's nice to have a table describing the various formats, but it does not help anybody to understand the meanings if there are no explanations for the used symbols.

All these as, bs, cs,... etc. are not described in any way, what should "Significand: 0abc" mean to the reader? --95.91.246.112 (talk) 15:24, 18 March 2023 (UTC)