The Microsoft manuals preach that all the compiler options in the Advanced Optimization dialog box are to be considered unsafe, in that they might lead to incorrect results (or just program crashes!). This is true for most of them, but often one of such options – namely, the “Allow Unrounded Floating Point Operations” – can deliver correct results and prevent you from inserting a bug in your application. Consider the following code:

Dim x As Double, y As Double, i As Integerx = 10 ^ 18y = x + 1      ' this can't be expressed with 64 bitsMsgBox (y = x) ' displays "True" (uncorrect)

Strictly speaking, the MsgBox should display False, because the X and Y variables shouldn’t contain the same value. The problem is, they do contain exactly the same value, because the values 1E18 e 1E18+1 are represented with the same 64-bit floating point Double value.

If you turn on the “Allow Unrounded Floating Point Operations” compiler option, you enable VB to reuse values already on the math coprocessor stack, instead of sticking to values stored in memory locations (i.e. variables). Because the FPU stack has a 80-bit precision, it can tell that the two values are actually different:

' if the program is compiled using the ' "Allow Unrounded Floating Point Operations" compiler optionMsgBox (y = x) ' displays False" (correct)

Summarizing, when you run a program in interpreted mode, or as compiled p-code, or as compiled native code but with the “Allow Unrounded Floating Point Operations” option turned off, all floating point math operations are internally carried out with a 80-bit precision, but once a value is stored into a 64-bit Double variable the result is rounded, and all subsequent expressions that use that variable will use the rounded result.

Conversely, when you run a code natively compiled with the “Allow Unrounded Floating Point Operations” compiler option turned on, VB can sometimes reuse the internal 80-bit value in subsequent expressions, and ignore the current value assigned to the variable. Note that you don’t have full control on this feature, and VB may or may not apply it, depending on how complex the expression is and how far the original assignment statement is from the subsequent expression that reuses it.