High-Precision arithmetic bug...

#1
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.
 

rconn

Administrator
Staff member
May 14, 2008
10,638
97
#2
And then the TCC session in which it is running immediately 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.
Please email your .btm to [email protected].

Note that @EVAL can generate arguments that are much larger than can be handled in variable substitution; however, TCC should be truncating them and not crashing.