Number
A number is, depending on scope, either a single precision floatingpoint number (when talking about scripting) or a range of numerical types when talking about config context.
Scripting
In SQF, there are multiple accepted number formats.
However, all of them will result in the same SCALAR
(typeName) value type.
The largest positive number that can be achieved is 3.4028235e38
and the largest negative is 3.4028235e38
.
It also is possible to generate positive or negative infinity values using either 1e39
(string representation: 1.#INF
) or 1e39
(string representation: 1.#INF
).
To check if a number is finite one can use the finite operator.
Decimal (Base 10)
A decimal number is your normal 0.5
syntax stuff with one extra: You may omit the initial pack of digits.
Some Examples would be:
5.197
0.47
16.0
.8314
12345
A regex catching these kind of numbers could look like this ((\.[09]+)(\b[09]+(\.[09]+)?))\b
Scientific Notation
The Scientific Notation is a way of expressing numbers that are too big or too small to be conveniently written in decimal form.
It starts of like a normal decimal and then gets expressed by an E
(Not casesensitive, thus e
is also valid) followed by an optional +
or 
sign and ends with a range of digits.
Some examples would be:
1.23E4 ⇔ 1.23 ⋅ 10^{4 } ⇔ 12300
5e2 ⇔ 5 ⋅ 10^{2} ⇔ 0.05
A regex catching these kind of numbers could look like this ([09]+.)?[09]+[eE][+]?[09]+
Hexadecimal (Base 16)
In SQF, hexadecimal (also base 16, or hex) is a positional numeral system with a base of 16.
They start either with 0x
or with a single $
.
This gets followed by one of the following characters: 0 1 2 3 4 5 6 7 8 9 A B C D E F
.
Note that casing does not matter, thus both 0xa
and 0xA
are valid.
Some Examples would be:
0xa5
$5C
$FFFFFF
0x123ABC
A regex catching these kind of numbers could look like this ((\$0x)[09afAF]+)\b
Config
Unlike scripting, configs actually do allow for multiple number types (Integer, Float, etc). They are properly stored with their corresponding type in mind.
class MyClass
{
myInt = 1; // integer
myFloat = 0.01; // float
};
// description.ext example
disabledAI = 1; // boolean: 0 = false, everything else = true (usually 1)
Floatingpoint Precision
Humans are typically used to performing mathematical calculations on the set of real numbers (ℝ), and there are no gaps between real numbers; there is always another real number between two real numbers. However, as mentioned above, every number in scripting is a floatingpoint number. Because any given floatingpoint number can only consist of a finite amount of bits (a computer's memory is finite after all), any given floatingpoint format can only represent a finite amount of distinct numbers. Consequently, there are gaps between floatingpoint numbers.
This induces the following problem: There are real numbers that the computer does not have a binary representation for (and that it therefore can not work with) because there is no representation for these numbers in the specific floatingpoint format used by the computer. Of course, by extension, this also applies to the Real Virtuality Engine  there are real numbers that it does not have a representation for.
This issue is dealt with by rounding to the nearest number that can actually be represented as a floatingpoint number.
n ∈ ℝ  n in Arma 3 (value of n toFixed 20 )


0  0.00000000000000000000 
1  1.00000000000000000000 
1.1  1.10000002384185790000 
2.5  2.50000000000000000000 
2.51  2.50999999046325680000 
Unfortunately, this rounding introduces a new problem in the form of unexpected, seemingly erroneous behaviour: For instance, despite being entirely correct mathematically, the expression 0.3 + 0.4 == 0.7
surprisingly returns false in Arma 3. In order to understand why this happens, examine the evaluation of the expression step by step:
 The 0.3 from the source code has to be rounded to 0.30000001192092896
 The 0.4 from the source code has to be rounded to 0.40000000596046448
 Now the addition can be performed: 0.30000001192092896 + 0.40000000596046448 = 0.70000004768371582 (that is the result with floatingpoint arithmetic; the result of the same addition in ℝ is 0.70000001788139344)
 The 0.7 from the source code has to be rounded to 0.69999998807907104
 Finally, the comparison
0.70000004768371582 == 0.69999998807907104
returns false
To add to the confusion, 0.3 + 0.4
will actually output 0.7 on the Debug Console or when used with commands like hint or systemChat  that is because numbers are rounded yet again when they are converted to String for the output. If this needs to be avoided, the toFixed command can be used to obtain the accurate value of a number.
Floatingpoint formats are designed so that their accuracy is highest for values close to the zero. As such, the gaps between floatingpoint numbers with small absolute values are also small, while the gaps between floatingpoint numbers with large absolute values become increasingly larger. For instance, any real number between 87,654,316 and 87,654,324 has to be rounded to 87,654,320 in Arma 3.
Consequences
 Fractional numbers should not be compared for equality. Instead of
0.3 + 0.4 == 0.7
one should use something like_res = 0.3 + 0.4; _res > 0.7  0.000001 && _res < 0.7 + 0.000001
. Note that this is only necessary if fractional numbers are involved; if only whole numbers are involved, this procedure is not necessary.  Large numbers can not always be incremented / decremented. For example,
87654320 + 1
returns 87,654,320 in Arma 3 (the next larger floatingpoint number after 87,654,320 is 87,654,328).