AI Math
Am I right or am I right?
Thousands of Norwegians mistakenly thought they'd won life-changing sums in last week's Eurojackpot after a manual coding slip at state-owned operator Norsk Tipping. Eurojackpot, a pan-European lottery launched in 2012, holds two draws per week, and its jackpots start at €10 million (about $12 million) with a rollover cap of € …
A trading system I worked on to integrate with our internal systems was connected to the London Stock Exchange. In testing everything was just fine and dandy.
In production a *small* glitch occurred - it received prices in GBX (Pence) and though they were in GBP (Pounds). Critically, the balance validation worked correctly, seeing GBX prices as it should, but when trades were collected or paid, it had already passed that step so just blindly transferred a sum that was 100 times more than it should have been. If you've ever dealt with unhappy stock market traders, you might guess how miserable they made everyone for a while. As bad as it was, my team got off not too badly, but in the order manager system team some heads ended up rolling.
That's what happened to me when a nephew sent me some stuff from Hong Kong. It was labelled something like HK$50, and instead of dividing by 13 the UK customs multiplied it by 13, resulting in a 13*13=169-fold error, and insisted I pay import duty on a "value" of £650 instead of less than a fiver.
There's some arithmetic detail hidden in the words...
"Eurocents to Norwegian kroner"
Euro cents, not Euros, so you must divide by 100 if applying a Euro to Kroner exchange rate.
Failing to divide by 100 is equivalent to multiplying by 100.
Multiplying by 100 when division was intended "squares" the error: a punter that won 1.00 EUR is going to be told they won 100 EUR which, x100, means they were told they won 10,000 EUR.
What I find most puzzling is why a lottery operator relies on a manual process for this?!
"Multiplied by 100. But the article says the amounts were inflated by 10,000x."
Yes, that is correct.
Instead of *dividing* by 100, they did not divide at all, that makes the winnings 100 times larger than they should have been.
Then they compounded this error by *multiplying* by 100, which makes the winnings 100 X 100 times as large as they should have been.
100 X 100 = ten thousand. 10,000 times bigger than it should have been.
The maths works fine.
No buddy, you're going to be a lot sorrier when a class-action lawsuit (or whatever the Norwegian equivalent is) lands in front of a judge who will undoubtedly decide that you are to pay for the costs of annulation of contracts that these "winners" contracted in good faith.
Nice try, but that's not how that works. Reporting errors that get fixed in hours don't get upheld in court or have penalties assigned unless you can very convincingly prove that someone deliberately did it. The contracts that lottery gamblers signed would not say "whatever the computer says, you get paid", but probably do have legally required figures for how the prizes are calculated which would prove the announced figures wrong. By the way, it also wouldn't work that way if the reported figures were dramatically lower than they should have been. The company wouldn't be able to pay the reported amounts and collect the difference. The only way a court would care is if the error wasn't corrected, and what they would do is mandate that the company correct their error and deal with any payment differences involved. Since the error was corrected before payments were dispersed, that's not going to happen either.
Yeah, sounds harsh, but if the widgets didn't wait for/check the money was actually deposited in their bank accounts then it sucks to be them.
The company may get a slap on the wrist but doubt there'll be compensation unless the company does it voluntarily.
This is Norway we are talking about, not the USA. People got annoyed, but no one will be suing anyone.
The head of the lottery company has resigned, and there will likely be some regulatory rules imposed (such as mandatory testing!), and possibly corporate fines. There have been a few cock-ups by Norsk Tipping in recent times, so a change of leadership makes sense.
Paying a multi-hundred pound bill at a UK Post Office in cash, I only realised the receipt showed it as hundreds of pence when I got home.
That was an overnight worry as to how I would ever prove it but, as I had hoped, their end of day audit had flagged the discrepancy between cash in tills and expected balances so they were already prepared when I arrived, They were rather sheepish and non-communicative but got it sorted out efficiently. Mistakes happen and I was rather sanguine and sympathetic about it; my righteous indignation and raised voice is reserved for those who aren't so cooperative in resolving issues.
Looking back, knowing what I now know of Horizon; I suspect they may even have been crapping themselves more than I was.
And, yes, I am more rigorous in checking receipts when I am handed them. Tomorrow's instalment; why you should always request a receipt from the self-service till.
A similar problem arises here Stateside at every petrol pump - if paying by credit card, one has to first key in the amount to pre-authorize. So, for example, if you think you're going to need <= $40 worth of fuel, you'd key in 40.
Except that every pump I've seen interprets the input as cents not dollars, so you actually need to enter... 4000.
There were occasions in the past before I was wise to this that I embarrassingly authorized only 40 cents or so to be taken from my card; I fear that if I ever encounter a pump that does it a sensible way (why would you ever need to authorize down to the cents level?) I'm going to wonder why a hold of $4000 has been placed on my card!
Wow...that's just, well, stupid and backwards
UK pumps preauthorise £99 without you entering anything
. Then the proper amount is deducted at the end. It has screwed up occasionally, but 99.9999% of the time.
Or is this a pay at kiosk rather than pay pay pump?
> old government system written in Cobol 60
Getting muddled with cobalt-60?
>> Many logical flaws were found in COBOL 60, leading General Electric's Charles Katz to warn that it could not be interpreted unambiguously
Usable COBOL, that might be found in a government system, appeared a few years later.
Trying to use COBOL 60 would have had worse fallout than cobalt-60 [1]
[1] now trying to think where we'd find a sunken collection of old LISP code, clean and pure, uncontaminated by COBOL 60: looking for the Scapa Flow of coding.
"conversion process from Eurocents to Norwegian kroner multiplied amounts by 100 instead of dividing them."
I would guess this pan EU lottery uses EUR (€) but with Norway's peculiar relationship† with the EU still retains the Krone (NOK) (which I presume means crown) and thus a floating EUR/NOK exchange rate. Roughly €1.00 ~ NOK 11.90.
The conversion I assume would be fixed at some time prior to the draw using some Forex derivative but would likely be entered manually which is where the error might have occurred.
My guess is the payouts were in € cents which would be divided by 100 and multiplied by 11.90 [¢->€, €->NOK] or reverse order [EU ¢->NO ore, NO ore -> NOK].
I can imagine that historically the conversion was to the smallest unit of the currency eg cent or pence and the divisor wouldn't always be 100.00 in pre decimal currencies eg between USD and £sd it would be 240. Ruritanian 1 Taler = 273.25 RUR farthings. Hence the required manual entry.
Classic failure to automate cock-up.
† Brexiteers might recall "Norway or nothing", others certain the latter prevailed.
"Surely any sensible person would have waited until the money was paid into their accounts before spending excessively??"
Well, I, for one, surely would. Then, as soon as I saw my Current Account credited, I'd move the funds into a Savings Account, just to hinder them clawing it back.
It wouldn't prevent a clawback, if one were supported by some good reason, but it would annoy them. And, if the winnings were large enough, I might even make a few quid out of it in interest. :)