Because of how floating point precision is handled in the SQF engine, the output is often truncated or rounded when displayed, but the value is actually different from what is displayed internally for calculations.
Description
Description
Details
Details
- Legacy ID
- 1561522384
- Severity
- None
- Resolution
- Reopened
- Reproducibility
- Always
- Category
- Scripting
Steps To Reproduce
Execute the following code in the debug console:
TESTVAR = 33.8225; TESTVAR_FLOORED = floor TESTVAR; diag_log text format["Apparent Integer Result: %1", TESTVAR*10000]; diag_log text format["Internal result of further operations: %1", (TESTVAR*10000)-(TESTVAR_FLOORED*10000)];
Compare the results to printf("%f", 33.8225f*10000.0f); in a MSVC compiled c++ application (which results in 338224.968750).
Additional Information
This truncation or rounding in display results in misinformation to the script writer and causes inadvertent bug chasing when the result is actually different from what is visually accessible.
See attached image for additional proof.
Event Timeline
Comment Actions
Basically, the value stored internally should be shown when represented as a string. Truncation or rounding not performed by the user is disingenuous and can lead to problems.
Comment Actions
Suggested fix is a function that converts the single point float values in the SQF engine into their string form with out any manipulation, or extending the functionality of an existing command like str (though there may be backwards compatibility issues where developers relied on this flawed behavior in their displays).
Comment Actions
Not sure why this was closed as a duplicate of the other issue. This is a different issue (and I was asked to make a ticket on any issues that result from the first ticket).
This is a bug. Numerical values are not displayed to the user correctly. This presents a fundamental problem in that what you see is not what you get, which leads to lots of issues. If you are having to do large integer math (like ACRE needs to do on frequencies in some cases) then it is helpful to know if you actually have an integer or not in your math, so you don't get unexpected results.
I am NOT asking for floating point precision to be increased but for the allowance of seeing what values we are actually working with in the engine (and it'd be nice if the scientific notation was dropped too, not sure what the benefit of that is).