OK, it is the 'nature of the beast' as they say.
So if I try to force a decimal place with:
INT(number * 100) / 100 ' or _ROUND, etc.
then am I just reintroducing the same floating point error again when dividing by 100?
It would seem then that PRINT USING is the only answer.
Ir’s not the same floating point error, but a *new* floating point error. Usually the computer can sort out when to round up/down a few decimal places (or else 1/3 * 3 would forever be 0.999999999999 instead of 1), but sometimes it still screws up. As you mention: it’s simply the nature of the beast.
Only solution I can offer in this case is just to up your precision level as much as possible, and hope it fixes the issue. Or write a custom function to convert to string and manually insert the decimal:
FUNCTION ex## (x##)
ex## = INT(x## * 100)
temp$ = STR$(ex##)
temp1$ = LEFT$(temp$, LEN(temp$) - 2) + “.” + RIGHT$(temp$, 2)
ex## = VAL(temp1$)
END FUNCTION
Floating point math removed — problem removed.
(You may need my routine to remove/convert scientific notation, if your values are too large. They’re here on the forums if you need them.)