來自微軟的資料鼓吹：高級優化對話框中的所有編譯選項都被認為是不穩定的，它們可能導致不正確的結果，甚至程序崩潰。對於其中的大多數，這種說法是正確的，但是經常有一個叫做"AllowUnroundedFloatingPointOperations"的選項能夠給予正確的結果，防止應用程序產生bug。考慮下面的代碼段：
DimxAsDouble,yAsDouble,iAsInteger
x=10^18
y=x 1'thiscan'tbeexpressedwith64bits
MsgBox(y=x)'顯示"True"(不正確的結果)
嚴格地說，由於X和Y變量不包含相同的數值，MsgBox將顯示False。可問題是，由於數值1E18與1E18＋1都以相同的64位浮點Double類型來表示，它們最終包含了幾乎相同的數值，最後的MsgBox結果將是True。
如果打開了"AllowUnroundedFloatingPointOperations"編譯選項，VB就能重用已在數學協處理器堆棧中的數值，而不是內存中的數值（比如：變量）。因為FPU堆棧具備80位的精度，因此就可以區分出這2個數值的不同：
'iftheprogramiscompiledusingthe
'"AllowUnroundedFloatingPointOperations"compileroption
MsgBox(y=x)'顯示"False"(正確的結果)
總結一下：當以解釋模式、或者編譯的p－code模式、或者編譯的native代碼模式但關掉"AllowUnroundedFloatingPointOperations"選項這3種方式運行一個程序時，所有浮點數字運算在內部都以80位的精度進行處理。但如果有一個數值是存儲在64位Double變量中，結果就是接近的了，並且，隨後使用那個變量的表達式也將產生近似的結果，而不是絕對正確的結果。
相反，如果打開"AllowUnroundedFloatingPointOperations"編譯選項後運行一段native編譯代碼，在隨後的表達式中VB就經常能重用內部的80位數值，而忽略存儲在變量中的當前數值。注意：我們並不能完全控制這個功能，VB也許對此生效，也許就不生效，這要取決於表達式的復雜程度以及最初分配數值語句與隨後產生結果的表達式語句的距離遠近。->
