Tom

]]>Simply test it by manually converting .03 decimal to binary and back again. Try with 1-byte, 2-byte, 4-byte and 8-byte binary variables. There will **always** be a loss of same small fraction. That is exactly why formats such as packed-“decimal” and binary-coded-decimal were invented in the first place. A value such as .03 **cannot** be accurately represented in binary form with an infinite number of bytes.

Don’t use binary data types (e.g., floating point) for fractional decimal calculations.

Alternatively, don’t use fractional values — always convert to integers. For example, don’t store dollars as packed (9,2). Instead, store as pennies with packed (9,0). The same digits are used, but there are no fractional portions. Do it all with integer math.

Of course, when you do that, you introduce multiplication by and division by 100, which tends to offset any advantage of using floating-point in the first place.

Tom

]]>Eval hfloat = decfield * 1.000005

I had to experiment to fing the right number of zeros, but it finally worked.

]]>