Why Excel doesn't work according to IEEE 754 8-byte

Question

The following expression evaluates to false in C #:

 (1 + 1 + 0.85) / 3 <= 0.95 

And I believe that this is done in most other programming languages ​​that implement IEEE 754, since (1 + 1 + 0.85) / 3 evaluates to 0.95000000000000007 , which is more than 0.95 .

However, although Excel should implement most of IEEE 754, too , the following evaluates the TRUE value in Excel 2013:

 = ((1 + 1 + 0.85) / 3 <= 0.95) 

Is there any specific reason for this? The above article does not mention any custom Excel implementations that could lead to this behavior. Can you tell Excel strictly according to IEEE 754?

Note that while most Excel questions should be asked at superuser.com, this question is about floating point arithmetic, which is a common problem in programming languages. From the point of view of this topic, Excel is a programming language such as C # or Java.

Answer 1

In the article you indicated , it is explicitly said about the implementation of something non-standard value with a value of 0:

Example when the value reaches zero 1. In Excel 95 or earlier, enter the following information in a new workbook: A1: = 1.333 + 1.225-1.333-1.225

2. Click cell A1, and then click Format Cells. On the Number tab, click Scientific Category. Set the decimal places to 15. Instead of displaying 0, Excel 95 displays -2.22044604925031E-16.

Excel 97, however, has introduced optimizations that attempt to fix for this problem. If the result of the addition or subtraction operation is equal to or very close to zero, Excel 97 and later will compensate for any error that occurs as a result of converting the operand to and from the binary file.

The unspecified “optimization that is trying to fix this problem” means that when using Excel for numerical calculations, caution should be exercised in strict agreement with IEEE 754. Perhaps using VBA (which is unlikely to have this “optimization”?) Could be a workaround.