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)

clarification requested for 'side effects - more info'

I worked through the article and considered it not well structured, spreading wrong / outdated info, as well as 'not very important' while neglecting other important. I changed many points, hope it's better now, to not suppress less important info I collected it in the end in 'side effects - more info'. The content is mostly unchanged taken from the old source. — Preceding unsigned comment added by 176.4.224.34 (talk) 10:16, 1 January 2025 (UTC)

comment reg. '"decimalxxx" / "binaryxxx"'

'x' is a common placeholder for an unknown numerical value, 'xxx' common for up to three digit numerals. We aren't talking here about 'decimal' or 'binary' in general, but about specific IEEE 754 formats decimal32, decimal64, decimal128, binary32, binary64, binary128, which are too long to name all in readable text, and benefit from grouping when talking about differences. Whoever doesn't like 'xxx', or has better understanding of 'enceclopedial style' is invited to improve, but please keep the functionality! 176.4.224.34 (talk) 10:25, 1 January 2025 (UTC)

Using 'x' like here is informal and vague. This must not be used in an encyclopedia. Note that anyone can define his own format with a number (size) not used by IEEE 754, such as binary80, which is used in practice and does not follow the IEEE 754 rules for interchange formats. This shows that using xxx in the way you want is blatantly wrong. — Vincent Lefèvre (talk) 21:45, 1 January 2025 (UTC)

no, xxx covers 80, 176.4.224.34 (talk) 22:52, 1 January 2025 (UTC)

You are contradicting yourself. — Vincent Lefèvre (talk) 23:13, 1 January 2025 (UTC)

comment on 'citation needed' reg. 'filling array'

this is info taken from the old version which was tolerated for years ( decades? ), I regarded it correct ( think it's self explanatory ), but less important, thus simply moved it. 176.4.224.34 (talk) 10:29, 1 January 2025 (UTC)

Unless you have a notable source showing that this is used, this is useless here and possibly misleading as readers might think that this is a good idea, while this is probably a bad programming practice nowadays (and note that this yields undefined behavior in C as the data are partly uninitialized). — Vincent Lefèvre (talk) 21:58, 1 January 2025 (UTC)

I didn't invent that info, just kept it because I do not! like suppressing info contributed and regarded valuable by others. 176.4.224.34 (talk) 22:54, 1 January 2025 (UTC)

In any case, you need to provide a source. See WP:RS. — Vincent Lefèvre (talk) 23:18, 1 January 2025 (UTC)

comment on 'denormal' vs. 'subnormal'

acc. to anonchatGPT denormal fits better, if you insist in change pls. explain.

In computer numbers, 'denormal' and 'subnormal' refer to different types of floating-point numbers that are smaller than the smallest normal number representable in the system.

Denormal numbers, also known as 'denormalized' or 'denormalized numbers', are floating-point numbers that are too small to be represented within the normal range of floating-point numbers but are supported by the system as an extension to the normal range. Denormal numbers have reduced precision, and computations involving denormal numbers may result in slower performance compared to normal numbers.

Subnormal numbers, on the other hand, are also floating-point numbers that are smaller than the smallest normal number representable in the system but are designed to be handled in a special way by the system. Subnormal numbers have full precision but are represented with less exponent range, allowing them to represent very small numbers close to zero without losing precision. Subnormal numbers are typically used to handle underflow situations where the result of a computation is too small to be represented by normal floating-point numbers.

— Preceding unsigned comment added by 176.4.224.34 (talk) 10:42, 1 January 2025 (UTC)

Well, first, you should not base your answer on ChatGPT as it is often wrong (or gives confusing information), at least on technical points.

The term "subnormal number" (also substantified as "subnormal") is well-standardized: used by ISO C (since at least C99), LIA-2 (2001) and IEEE 754-2008 and later (and also even in the old IEEE 854-1987 standard, according to Goldberg, which might be one of the first uses). It designates a non-zero floating-point value whose exponent is minimal (= emin) and whose leading digit of the significand is 0.

The IEEE 754-1985 standard (which supported only binary FP arithmetic) used the term "denormalized number" with exactly the same meaning. IIRC, this term was dropped in favor of "subnormal number" because it could be understood in some contexts as a number that is not normalized (BTW, the C standard has the term "unnormalized floating-point number" for non-zero FP numbers that are neither normalized nor subnormal).

Goldberg says that in the IEEE 754-1985 standard, subnormal numbers were called "denormal number", but in my copy of the standard, it was just "denormalized number". I suspect that "denormalized number" and "denormal number" were used interchangedly at that time.

Nowadays, the non-standard terms "denormalized" and "denormal" should really be avoided due to the possible confusion with values that have not been obtained after a process of normalization. BTW, this wikibook chapter "Floating Point/Normalization" says:

We say that the floating point number is normalized if the fraction is at least 1/b, where b is the base. In other words, the mantissa would be too large to fit if it were multiplied by the base. Non-normalized numbers are sometimes called denormal; they contain less precision than the representation normally can hold.

Note that nothing is said about the exponent. There you have a meaning that is different from what ChatGPT says. — Vincent Lefèvre (talk) 23:12, 1 January 2025 (UTC)

from the wikibook you cited: "Non-normalized numbers are sometimes called denormal; they contain less precision than the representation normally can hold.". So what you insist in is personal preference, and not worth disturbing the work of others or start edit wars. 176.4.225.16 (talk) 07:22, 2 January 2025 (UTC)

'Subnormal' is the term used by the latest versions of the IEEE754 standard. It has a specific meaning and is the preferred term when discussing those numbers with an exponent at its minimum value, and a "hidden" bit of 0. —scs (talk) 18:36, 3 January 2025 (UTC)

comment on Infinity vs. infinity

meaningless nitpicking, but seems a pleasure for the editor, it wasn't my wording but taken from old source, consider it correct because here it's not about the general concept of 'infinity', but a name! for a special value, and names are capitalized in english? But other may know better ... — Preceding unsigned comment added by 176.4.224.34 (talk) 10:50, 1 January 2025 (UTC)

The word "infinity" is not capitalized in the IEEE 754 standard, not in the ISO C standard either, not in the LIA-2 (ISO/IEC 10967-2) standard either. Goldberg's well-known article What Every Computer Scientist Should Know About Floating-Point Arithmetic does not capitalize it either (unless it refers to a section named "Infinity", but just because this is the title of a section). So the common practice is not to capitalize "infinity". — Vincent Lefèvre (talk) 22:11, 1 January 2025 (UTC)

if it pleases ... pls. be as accurate in the articles you are editing ... 176.4.224.34 (talk) 22:56, 1 January 2025 (UTC)

requesting discussion / consensus about 'performance'

Besides nitpicking reverts reg. personal preferences by VL and MO there is a problem with this point. Besides the intention for more accurate results IMHO the performance is the most important info interested users should get about this datatype, as it has wide stray, and may harm work started with basic arithmetic and then becoming slow when other mathematical functions are requested. I was astonished both by the widespread assumption of 100 to 1000 times slower, which could not be reproduced for basic arithmetic, as well as several thousand times slower e.g. for trigonometric functions. To avoid unpleasant surprises for programmers this information should be made public, it is simply correct, but two? users do not want to accept it and argue against it with formalisms. If I still can't find a 'reliable source' I will write a paper about it, until then please:

• leave the information as provisional / WIP in the article,
• especially not to damage other correct work with 'silly reverts'

176.4.225.16 (talk) 07:55, 2 January 2025 (UTC)

Reverting due to complete failure to follow WP:V and WP:OR is not 'nitpicking'. You've got to cite sources. These are Wikipedia's core policies and are not optional. MrOllie (talk) 13:26, 2 January 2025 (UTC)

Yes, it would be good to have some information about relative performance, but it has got to be well-sourced information based on authoritative, reliable sources — not handwaving and guesswork.

Since almost everyone has hardware implementations of binary floating point available, and almost nobody has decimal f.p. hardware, I think it's unquestionably true that binary is going to perform quite significantly better than decimal for the foreseeable future. Encouraging programmers to use binary unless they absolutely need decimal is not "scaring them off": it's good, basic, accepted practice.

I'm noticing a growing tendency by some to assume that IEEE754 binary floating-point is "broken" or "inherently inaccurate", and that this is a "problem" that can be "fixed" by switching to "obviously superior" or "inherently accurate" decimal formats. But this is a trend that must be resisted! The way to deal with floating-point inaccuracies is not to blindly switch to a massively less efficient decimal format — the way to deal with those inaccuracies is to understand them and (if necessary) to work around them appropriately. The fact is that any finite-precision floating format is, by definition, inherently imprecise. Decimal isn't "more accurate" than binary; it's just differently precise. —scs (talk) 16:13, 3 January 2025 (UTC)