In AutoMod, there is no Boolean data type, but there are integer constants named true (equivalent to the value 1) and false (equivalent to the value 0). Unfortunately, careless use of these constants—particularly in relational expressions—can lead to some unexpected and hard to identify bugs.
Consider the following code snippet, which checks whether the simulation has encountered an error condition:
set VI_errorStatus to FI_getErrorStatus ()
if VI_errorStatus is false then begin
// No error has occurred...
print "No error has occurred." to message
end
else begin
// An error must have occurred.
print "Error with code " VI_errorStatus " has occurred." to message
end
This code works pretty much as you might expect it to. If no error has occurred, FI_getErrorStatus () returns false (0), otherwise a non-zero error code is returned. Not only does this reflect the binary nature of Boolean expressions (if it’s not Boolean false, it must be Boolean true), it also follows the common convention that an integer value of 0 maps to the Boolean value false, while all other integer values map to the Boolean value true.
Given the binary nature of Boolean logic, you might expect, by negating the the if condition and switching the if case with the else case, the following code snippet to be exactly equivalent to the above:
set VI_errorStatus to FI_getErrorStatus ()
if VI_errorStatus is true then begin
// An error must have occurred.
print "Error with code " VI_errorStatus " has occurred." to message
end
else begin
// No error has occurred...
print "No error has occurred." to message
end
However, if that was what you expected, then—in AutoMod, at least—you would be completely wrong.
Why? Because, in AutoMod, the constant true has the integer value 1; it is not equivalent to the Boolean value true (which you might more conveniently think of as being defined as not false). If FI_getErrorStatus () returns an error code of 1, then the code will work correctly and will report an error with error code 1. However, if any other error code is returned, then the code will report that no error has occurred at all! Since an integer expression in AutoMod can be any whole number in the range [-2,147,483,648, 2,147,483,647], we find that there are billions of holes in the second version, yet none in the first.
The problem is that we have assumed that the AutoMod constants true and false exhaust all possible outcomes, when they do not even come close—they are simply two regular integer values, out of a population of over 4 billion, yet they have highly misleading names. In particular, by comparing whether an integer variable has the integer value true, we are simply checking if it is 1—we are not checking whether the integer value is the Boolean value true (any value other than 0). In order to correct the second version, we need to ensure that the value returned by FI_getErrorStatus () is not equal to false, rather than being equal to true:
set VI_errorStatus to FI_getErrorStatus ()
if VI_errorStatus <> false then begin
// An error must have occurred.
print "Error with code " VI_errorStatus " has occurred." to message
end
else begin
// No error has occurred...
print "No error has occurred." to message
end
This third code snippet is now directly equivalent to the first.
Whenever a piece of code does something unexpected—whenever it violates the principle of least astonishment—you should sit up and take notice, because otherwise you’re going to see difficult to detect bugs creep into your models.
What can we learn from this simple example? Primarily, that care needs to be taken when making trivial Boolean relations in AutoMod. I would recommend, if you write simulations in AutoMod, that you treat any comparison of an integer expression to the constant true as a red flag. Instead, you should compare integer expressions to the constant false.
That is, instead of:
someIntegerExpression is true
use:
someIntegerExpression <> false
And, instead of:
someIntegerExpression <> true
use:
someIntegerExpression is false
Mike Allen
President, Hindsight Consulting, Inc.
