Comment by d2p | Hacker News Reader

Comment by d2p | Hacker News Reader

I've seen this a lot too; but it's not the weirdest thing I've seen on a receipt... We once ate at The Boot Room at Cheshire Oaks and when we got the bill, the numbers didn't add up! (I don't add these things up but since the things we ordered were fairly round numbers and should've been just below £20 and the bill was just over, it was obvious something was fishy).

I totalled the numbers up again and the total was exactly £1.50 less than the total shown on the bill! My wife (having no faith in my basic adding skills) pulled out her phone telling me "don't be silly" and added them up to get the same result as I had.

We asked the waiter about it, who disappeared off to get his own calculator.. He added things up, looked confused and then took it off to the manager. She then repeated the process on the calculator and also looked confused, unable to explain what had happened. They gave us £1.50 in cash, apologised and then kept the receipt (I guess they didn't want us posting that on twitter!).

To this day I've no idea what happened. You could suggest that some programmer somewhere is getting rich off this, but it seems rather unlikely to me. I'd really love to know what the cause was (and whether the manager ever reported it further up the chain; because this seems like a rather serious error to me.. how often does it happen? is it always £1.50? did the issue get found/fixed?).

I develop software algorithms for automatic processing of invoices and receipts. I have analysed hundreds of them and you'd be surprised to see how many contain errors like totals not matching the products, VAT breakdowns not matching the percentages, rounding errors etc.

In my experience this is usually because 'financial software' systems used to create invoices is sold by companies with 90% sales people, and maybe one or two developers. There seems to be little to no quality control. No one seems to care, since 'financial software' is very lucrative anyway.

In the beginning I tried to report the faulty invoices to the suppliers, thinking that the'd immediately press the big red emergency button and fix it, but in most cases the servicedesk employee does not care or even understand what I am talking about. Most of them send the 'thank you for your report, we are working very hard to fix the problem' email, but never actually fix it.

I could understand if something was a few pence out and it seemed like it could be a rounding error; but exactly £1.50 on a bill of around £20 doesn't seem like it could be rounding/tax/etc.

(In the UK, all prices shown in the menus are inclusive of VAT and then the total on the bill shows how much of the total is the VAT, so both the amount you can add up yourself from the menu and the line items shown on the bill should match the total you're paying perfectly).

I've seen a register app coded in Javascript.

So what? There are ways to do precise calculations in JS; usually you just use some library.

This one did not.

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.

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.

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.)

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.

As dragonwriter points out, there are many, many places where non-integer math ends up taking place - taxes, discounts, coupons, three-for-ones, etc.

> if you do all your calculations in cents

That would certainly have been a good idea also, I bet.

How would a "three-for-one" action end up with floating point inaccuracies? I imagine the price for three items would tend to be dividable by three.

Floating point is intrinsically inaccurate. You can't use it to handle money.

With floating point, the assumption (x*y)/y = x does simply not hold.

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.

> I imagine the price for three items would tend to be dividable by three.

"Buy one scroodad for a dollar, get two free."

"Three widgets for $2, limited time only!"

"$5 each, or three for $10"

Oh man, having read this now every obsessive like me is going to be hand-adding every bill they ever get from now on. Adding up numbers is just about the only thing you'd think you could rely on even the most dunderheaded computer system to get right :(

I know; it's the sort of thing that if someone told me, I just would not believe them. This is such basic crap that the idea that some production till could get it wrong seems inconceivable.

They could have that £1.50 back if they could give me an explanation! =)

If it was off by 5%, there could be some weird reduced-rate VAT @ 5% (https://www.gov.uk/vat-rates) not being printed out separately but included in the total nonetheless.

If I remember correctly, most booze is at the full 20% rate. I can imagine a mistake like this happening at least.

Of course, if it wasn't off by 5%...

VAT is clearly marked on the receipt so it wasn't that. If it was something simple like this, I think it would've been obvious (if not to us, at least the manager working there!).

The bill was totally itemised, the total just wasn't the sum of all the numbers above it. I really wish I'd taken a picture of it now (I didn't really expect them to take it off me, I really expected them to explain that I was being a doofus) :(

Reply on news.ycombinator.com