Talk:Catastrophic cancellation

Decimal representation

[bs 2021-02-03: but: in floating point calculations with today's computers, values taken from a decimal representation have implicit deviations resulting from the decimal -> binary conversion of up to! -/+ 0.5 ULP (unit in last place), for each operand!

(there must be no deviations, but most values have some, (0.0, 0.5 and 1.0 are 'clean', 0.1, 0.2, 0.,3 0.4, 0.6, 0.7, 0.8 and 0.9 are not, less than 0.2 percent of the values with 4 decimal places can be represented binary accurate) the deviations can! also - partially - balance out in the calculation, this is a matter of luck, but in the worst case two maximum deviations add up),

in subtractions of similar large values the higher bits of the operands balance themselves out and the bits remaining as significance of the result consist to a certain extent of rounding deviations which now play a - relative to the result - larger role,

the absolute error is not larger than the sum of the deviations of the operands from the 'real' values, but the relative error can dominate the result (e.g. if from a value whose last bit is 'just rounded up' a value is subtracted whose last bit was 'just not' rounded up, and if because of the similarity of the values and the cancellation only exactly this last bit remains as result. therefore 'catastrophic'. (please excuse and / or improve my 'bad english')] 77.1.203.101 (talk) 11:52, 3 February 2021‎ (UTC)[reply]

I added a worked example of radix conversion. I don't think this page should just grow into a compendium of all types of error that can arise in numerical algorithms, though, just because they might be amplified by catastrophic cancellation! What's important is that catastrophic cancellation is a problem of questions you ask about approximate inputs, not a problem of floating-point arithmetic per se. Taylor Riastradh Campbell (talk) 21:04, 4 February 2021 (UTC)[reply]

my 'problem' is that the statement 'there is no rounding error introduced by the floating-point subtraction operation' is valid for pure - theoretical - fp-math under special conditions, but readers will evaluate it with sight on 'practical' math as performed by their pc's, and that suffers from two influences: 1. most programs don't use subnormals, and when normalizing the subnormal sterbenz-lemma results existing inaccuracies are 'blown up', 2. sterbenz-lemma works for pure binary values, but most of values computed by humans with their pc's today are converted decimals, and for those the percentage of being exact shrinks by a factor of 0,2 for each decimals place precision the original values were given (20% of xy,0 .. xy,9 - 4% of xy,00 .. xy,99 - 0,8% of xy,000 .. xy,999 and so on), thus the sterbenz lemma is a nice theory, but will lead users on the wrong track who look for practical info, would you mind adding appropriate info about that? 77.0.112.186 (talk) 21:52, 4 February 2021 (UTC)[reply]

I don't understand.

IEEE 754 has had subnormals from the beginning; most programs on PCs do use them in the event of underflow, unless they go out of their way to enable a nonstandard flush-to-zero bit in the hardware. But I'm not sure why that's relevant here—catastrophic cancellation applies with and without gradual underflow, and there is no underflow in any of the examples on the page.

The Sterbenz lemma is true in binary and decimal floating-point arithmetic, including the IEEE 754 arithmetic that just about every computer today uses in the real world—it's not limited to idealized theoretical conditions; it is essential to the correctness of (and error bounds on) many real-world numerical algorithms. The floating-point difference in the example is exact; it's the decimal to binary conversion that is approximate, and it's the real number subtraction (not floating-point) that amplifies the error.

Subtracting nearby approximations—no matter what the cause, whether measurement error or series truncation or polynomial approximation or rounding—is what leads to catastrophic cancellation. This page doesn't need to have a compendium of all possible causes of errors that catastrophic cancellation will amplify: any kind of error in any kind of arithmetic can lead to catastrophic cancellation.

Are you saying there is a factual error in the text, or just that there is some missing guidance? What is the factual error or the practical guidance that you think is missing? What did you hope to see that is not exhibited in the radix conversion example? Taylor Riastradh Campbell (talk) 05:21, 5 February 2021 (UTC)[reply]

Proposed merge of Loss of significance into Catastrophic cancellation

Article is beyond repair. Given how the only example of LOS people give happens with CC, and how the CC article actually does a better job showing how it applies to fp (binary64), this article has no use at all. Artoria 2e5 🌉 13:56, 30 March 2021 (UTC)[reply]

Taylor Riastradh Campbell, your thoughts?

I wrote the CC article after I tried editing the LOS article into passable shape and gave up on it as totally unsalvageable. I also replaced most links about catastrophic cancellation in articles such as Floating-point arithmetic so they point here instead of to LOS. The ones I left might take a bit more work to sort out, mostly because neither LOS nor CC is a good reference, or because the attribution of error is wrong in context. Other than those remaining links, I don't see any value in keeping the LOS article around as is, on its own or with any content moved here. (The quadratic formula example, if substantially revised and simplified, might be worth moving to Quadratic formula. But I don't think the CC article needs to be a compendium of all ways catastrophic cancellation manifests in numerical algorithms.) Taylor Riastradh Campbell (talk) 22:12, 19 November 2021 (UTC)[reply]

OK, this sounds like WP:TNT, so I've added the redirect rather than merging. Klbrain (talk) 05:50, 1 September 2022 (UTC)[reply]