This is not really the way I wanted to do this because it's not a question, but I can't find any other way to handle this issue... Specifically, the following code (in a .btm file): Code: SetLocal On Error Goto ErrOut SetDOS /F0,4090 Set R=1.41666<4,077 More 6's>6667 Set S=%@Eval[%R*%R] @Echo Evaluation Worked! @Echo Value of S: %S @Echo Before Iff 1 Iff %S != 2 Then @Echo Not Equal Two! Else @Echo Equal Two! EndIff EndLocal Quit 0 Produces the following output (note no "@Echo Off"): Code: SetLocal On Error Goto ErrOut SetDOS /F0,4090 Set R=1.41666<4,077 More 6's>6667 Before Evaluation... Set S=2.00694444,079 More 4's<>4445 Evaluation Worked! Value of S: 2.0069444<4,079 More 4's>4445 Before Iff Iff %S != 2 Then After which TCC session in which it is running immediately terminates without notice. Further testing showed that if the precision is 146 (i. e. SetDOS /F0,146), the .btm file runs to completion. If the precision is 147, the result is a standard windows message box "TCC has stopped working. Windows is searching for a solution to the problem", after which the TCC session terminates. And if the precision is 148 or higher, again the TCC session terminates without notice. While I will be the first to admit that this problem is not really an issue in the "real world" (I was just playing around), I also think that since Rex went to the trouble of writing code to handle high-precision arithmetic in the first place, he would also hope that it runs correctly in all situations.