Unit conversion corrupts exactness of values

[wangnick]

The example given in #34 decodes a.o. the third field of the telegram as 805.490000000000009094947017729282379150390625 m³.

However, the original BCD-encoded raw value decodes to 80549, and the multiplication factor referred to in the VIF table is 0.01, so the result is expected to be 805.49 m³.

The loss of exactness is is caused by the BCD-encoded raw value being multiplied by the factor before conversion into Decimal in telegram_variable_data_record.py:159, and then the resulting Decimal representing its value to the last digit upon conversion to string. Changing this code to te.ENCODING_BCD: lambda: decimal.Decimal(tdf.decodeBCD)*decimal.Decimal(str(mult)) fixes the issue.

A similar issue exists for ENCODING_INTEGER with multiplication factors smaller than 1 in line 158.

It might be worthwhile to consider storing the multiplication factors in the VIF table as Decimal in the first place, to avoid non-exactness creeping in altogether, given that Decimal(0.01) actually produces Decimal('0.01000000000000000020816681711721685132943093776702880859375').

Alternatively, one could consider to abandon the use of Decimal altogether, and rely on float.__repr__ to do the string conversion job reasonably.

KR, Sebastian

[hmaerki]

I just today while adding typehints stumbled over the code you mentioned.

Alternatively, one could consider to abandon the use of Decimal altogether,

That was my impression too.