I doubt the floating point errors are going to make much of a difference with the numbers the average register has to deal with. Javascript can represent integers up to 9007199254740991 accurately, so if you do all your calculations in cents your register can process a little over 90 trillion dollars before things get problematic.
Floating point numbers can accurately represent integers, so if you have all your prices in cents, you end up with (x * 3) / 3, where each number in that calculation is an integer. No inaccuracy there. Of course there is no reason for a register to actually perform this division in a three-for-one action, it can just replace (x * 3) with x, or subtract (x * 2).
I agree as much as the next person that you shouldn't represent money with floating point numbers, but I disagree that cash register software written in Javascript must automatically be incorrect (or more so that similar software in a different language). And I don't even like Javascript.
Floating point can accurately represent more than just integers. That does not mean that they can accurately perform mathematical operations on them.
I'd assume that division is implemented as multiplying with the reciprocal (because thats faster). If that's correct, then any division by 3 (or any other number that is not of the form 2^i) breaks your cash register.
Because 1/3 represented as a floating point number equals 0.33333333.. and so on but not indefinitely, 3 * 1/3 = 0.99999999.. - which would be equal to 1 if you were using real numbers. But you don't.
Or the first time you need to multiply by a non-integer, for tax or other purposes, and floating point imprecision affects the side of a rounding boundary you end up.
And then, in that very very rare case, the customer pays one cent more, or one cent less, and nothing bad happens? And since all amounts are in a whole number of cents, you can round to an integer after each such multiplication, and the floating point imprecision doesn't slowly add up. You could even subtract some epsilon before rounding to ensure no customers are never negatively affected by rounding.
Maybe I'm getting this all wrong, as I've never had to work with a register, nor do I have any experience with the software involved, but I hardly see the problem in accumulating a few cents of inaccuracy over time.
This is exactly the scheme from Office Space - minus a decimal shifted the wrong direction...
The problem is accumulating that inaccuracy when there are well-known, battle-tested libraries and data-types available specifically to avoid that problem. Except, maybe not as well-known as they ought to be...
People these days tend to have no idea how numbers are actually stored in bits and bytes. I'm more likely to find an English major who would be able to remember Big-Endian vs Little-Endian (albeit in the original Swiftian context) than a web developer who has any idea what that means. Forget about mantissas and exponents in floating point, or two's complement integers.
Paying taxes on your purchase is a very rare case?
Anyway, yes, your main thesis right: it's entirely possible to do this with Javascript without screwing it up. But it wasn't in this one particular case.
> Paying taxes on your purchase is a very rare case?
I think the point is that the situation where floating point error changes the result when rounded to cents is rare. Which is true, except when it is not (e.g., if you happen to have a price that tickets commonly hit that results in an error.)
