Summary
When using script SmartNames to perform numerical calculations that result in decimals, the result will sometimes have an infinitesimally small decimal appended on.
We are having a problem with script SmartNames not calculating correctly. Please see attached screenshot. Certain numbers work and others do not, can’t determine what decides whether it comes out correctly or not but it seems the more “normal” decimals come out correct, such as 0.25, 0.375, etc. Attached is a workflow containing the pictured SmartName.
Symptoms
For example, if the SmartName calculates <code>1 - 0.3757</code>, the expected result would be <code>0.6243</code>. The script SmartName, however, returns <code>0.6243000000000001</code>.
Or if the SmartName calculates <code>1 - 0.37501</code>, the expected result would be <code>0.62499</code>. The script SmartName will return <code>0.62498999999999999</code>.
Solution
This issue is a result of the javascript engine Automation Engine use in script SmartNames.
It converts the numbers to binary to do the math, then converts it back. Certain decimals cannot be expressed cleanly in binary, so it uses the closest approximation instead and then converts it back to a decimal which results in an extra decimal such as .000000000001 added or subtracted from the expected result.
The solution is to use the following function and method inside the script:
parseFloat(number.toPrecision(x)));The parseFloat function rounds and returns a floating point number. The .toPrecision method truncates the result to a certain number of decimal places. The x value should be replaced by how many decimal places (maximum) are desired in the result. For example:
For further reading about this issue, read this simple explanation of the problem: http://stackoverflow.com/questions/588004/is-floating-point-math-broken#answer-27030789
| Article information | |
|---|---|
| Applies to | Automation Engine all versions |
| Created | 19-Aug-15 |
| Last revised | |
| Author | DAPL |
| Case Number | |