Decimal value different in 11.20 SR5 (or later) compared to previous version

A calculation resulting in a decimal value gives different value in 11.20 SR5 (or later) compared to previous releases. 

The issue can be seen as a variation on the last decimal digits, when expanding decimal values to full decimal length.

Symptoms can be seen in below context and areas;

• Aggregated decimal result
• Timestamp's underlying decimal value representation
• Comparison of expected equal values fail
• Loaded decimal value 

All decimal values in QlikView are stored as floating point values. Floating point values are by definition not exact values, which means that there can always be a variation on the last decimal digit. The value length is statically 17 digits, including the integer and the decimal components of the decimal value. See article below for more details and references;

Floating point value precision in QlikView
Decimal values get incorrectly rounded

QlikView 11.20 SR5 introduced an improvement of floating point value precision. The reason for the improvement is to allow better precision for millisecond representation in Timestamp values. 

The practical effect of the improvement is that an identical calculation in 11.20 SR4 (or earlier) and 11.20 SR5 (or later) can give two different results. The variation is on the last decimal digit, but can of course  affect the second last decimal digit if the variation changes the last decimal digit from 9 to 0 or from 0 to 9. The improvement is considered to give a more exact floating point value, and will not have a negative effect on calculation results. 

The increased floating point precision in QlikView 11.20 SR5 (and later) does not make calculations incorrect. It is likely that the previously observed result is also not exactly accurate compared to the source data, which is in line with the nature and expectation of using floating point values for decimal value representation. 

If the result is not inline with expectations, there are several techniques to improve the value precision, as exemplified in articles below. 

Decimal values get incorrectly rounded
Rounded numerical values sometimes get unexpected results
Numeric values not the same in QlikView as in source data

NOTE: The floating point precision can be improved, but a decimal value in QlikView should never be assumed as exact. There can always be a variation on the last decimal value.

In logical comparison the result can differ if one of the compared values is unexpected due to the increased precision. For this scenario please refer to article below, which explains why decimal value should not be used in logical comparison. 

Comparison of decimal or timestamp values do not work