Despite 128-bit Decimal Floating Point (DFP) Encoding, Apple – Pages, Numbers, and Keynote Calculations Still Cannot Handle Certain Rudimentary Fractions
**Background on the issue:**
Before, June 25, 2019, Numbers would tend to raise my suspicions about its accuracy when yielding errors that Apple came to eventually acknowledge as a limitation with Binary Coded Decimal (BCD) encoding since ‘discrepancies become more apparent when amplified through certain types of calculation chains.’ In my case, a calculation chain involving a continuous subtraction of the [previous cell] – 0.1 eventually led to long decimal values that were far more precise than I usually needed but not accurate. For example, using a first cell as 1 then subtracting 0.1 from it and dragging the formula to more cells, by the time I was up to 0.1 – 0.1, the provided result was not 0 as it should have been. I notified Apple Support, requiring not only a senior advisor but a report to Apple engineers, then about 6 months to a year later the following happened.
When Pages, Numbers, and Keynote were updated to versions 8.1, 6.1, and 9.1 respectively, on June 25, 2019, Apple announced a major update to their calculation engine, which seems to be shared not only between the macOS versions of the apps but between the iOS/iPadOS and iCloud versions as well. Apple demonstrated that a calculation such as = 10.0 – 9.8, which ‘[i]n previous versions…’, ‘…results in a value of 0.199999999999999’, ‘now results in a value of 0.2.’
Apple release notes article: [https://support.apple.com/en-us/HT210179](https://support.apple.com/en-us/HT210179)
**What is the issue?**
Unfortunately, the precision error (or a very similar issue in effect) that Apple attempted to resolve is still present (in August 24, 2020) and observed when multiplying simple fractions (properly formatted as such in their cells) by positive integers. For example, for the first 32 integers, errors were observed for the multiplication products of 2 halves, 9 ninths, 27 twenty-sevenths, 30 thirtieths, and 31 thirty-firsts. For each of these calculations, the correct answer is 1. However, Numbers provides the answer, 0.999999999999999.
Visual proof of the issue: [https://imgur.com/gallery/b5gXoow](https://imgur.com/gallery/b5gXoow)
The issue has been reported to Apple Support, leading to a discussion with senior Apple advisor, leading to a report has been sent to Apple engineers. I have been told that Apple engineers are investigating but there is no timeline for resolution. If there is a resolution, an update will come in the form of a knowledge based article (likely on a section of https://support.apple.com) or in the software (likely through a software update would have accompanying release notes).
**What else and who else could be effected by this issue?**
Since the earlier version of this issue effected a variety math operations, it is possible that this issue could also effect the answers of more than some integer to fraction multiplication. For anyone formatting cells as fractions in Pages, Numbers, or Keynote, I would advise extra caution. Even if you can tolerate the small level of inaccuracy for any given calculation, it is possible that in a calculation chain, as Apple noted in their support article, the discrepancy could become more apparent when amplified.