Slashdot Mirror
Moving Decimal Bug Loses Money
mario.m7 writes "Poste Italiane, the Italian postal service, suffered yesterday from an abnormal computation in ATM and credit card operations, since the decimal comma was not taken into account. The whole sum was therefore multiplied by 100, resulting in a 115,00 Euro transaction being debited as 11.500 Euro! Thousands of accounts are deep in the red and locked (link pumped through translator), so that no more operations are possible. Poste Italiane is gradually recovering the problem, fixing the error and re-crediting the sum debited in excess. Consumer associations have offered support to clients in case this lasts longer and causes damage."
You mean 11,500 Euro as 11.500 Euro.
I always do that, I mess up some mundane detail!
I am officially gone from
Our Comma to separate numbers and periods to indicate decimal are far superior to your backward period to separate numbers and comma to indicate a decimal number!
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
1,00st post!
Good thing the programmers will be shielded from any consequences from this little 'bug'.
It doesn't matter that it caused potential harm to clients, corporations in the form of losses, lost time, expenses, etc.
The simple programmers just need to release a hot-fix or service pack.
Now if these were engineers, and I mean real engineers not "software engineers", there would be consequences.
Their licenses could be revoked, they could be investigated for incompetence, and held professionally and personally liable for any bugs.
But please, keep on purchasing software with NO WARRANTY, or NO FITNESS FOR A PARTICULAR PURPOSE, and that contains KNOWN DEFECTS.
Gotta keep the programming industry alive, and don't wanna stress theses "engineers" too much.
It's like the little penny tray. The pennies are for everyone. And we're just taking fractions of a penny here.
This is the same in my bank, if you type in . it gives an error. In addition it requires you to type in the ,00 too, and next to the sum text box is an example like "150,00".
Having comma/decimal as a separator is stupid anyway, space does just fine - 150 000.35
int64 Unsigned: 0 to +18,446,744,073,709,551,615
You mean I cannot transfer my 18 quintillion, 446 quadrillion, 744 trillion, 73 billion, 709 million, 551 thousand and 615 dollars (or in easier words 18 billion billion dollars) as a single transfer from my banking account? I need to do two of them? This is outrageous!
I never understood why the hell Europeans swap periods and commas. Grammatically it doesn't even make sense.
A period ends a sentence or statement, which to me should imply a whole number. A comma is simply a separator, used within sentences. So why would it be used to separate decimals?
It would be like writing a sentence this way:
I went to the supermarket to buy some cola. cabbages. and condoms,
Maybe there's a very good reason for it, but I don't see it.
Regarding the story on hand, that really sucks. I wonder if they will pull the same garbage as American banks where customers only have 60 days to report a problem otherwise nothing will be done. Whereas, if the bank screws up in your favor, they could go into your account 20 years from now and withdraw whatever extra money they gave you.
They got it backwards. They're supposed to take fractions of a penny from many thousands of people, not many thousands of pennies from each person.
There's a reason we separate the data model from the external view and internal controller mechanisms. A moving decimal shouldn't affect the internal math, it should be nothing more than a harmless display error. The fact a moving decimal actually affected the internal management is sad. Well, maybe I'm being an elitist boob, but this seems more like negligent high level design that compounded a low level bug into being much worse than it should have been.
"Sorrow is better than laughter, for by sadness of face the heart is made glad." [Ecclesiastes 7:3]
It's just like in Superman III, but backwards!
Using strings to store numbers internally is wrong, it just is. It's slow, wasteful, and unnessecary. I don't think I've ever (in 20 years of coding) needed to store something bigger than 2^64, but if I did, there are plenty of options (e.g. BigDecimal in Java, bigint in Perl, etc) which are essentially unlimited in size. Doing math with strings is just such a horrible concept :) As for precision floats (i.e. fixed point) there are real solutions for that issue in most languages too. String isn't one of them.
Exchanging your data with other systems (e.g. generating a web page, or XML, or whatever) is of course an entirely different story, you do what makes sense for the requirements. XML Schema, for example, mandates that a parser has to accept up to an 18-digit value for the digit type, but doesn't set an upper bound. So you need knowledge of the parser to know how to transfer very large values.
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
Huh, haven't you heard of BigInteger like data types ?
They are pretty common in accounting in various languages...
http://java.sun.com/j2se/1.5.0/docs/api/java/math/BigInteger.html
Everything I write is lies, read between the lines.
I made a similar mistake recently... I made a (.NET) data entry software that received monetary quantities as user input, and I converted them without taking into account the Windows settings for decimals and thousands separators.
.when converting, but it wasn't nice, messed with all of the higher ups' reports and everything ("Hey, hadn't we sold about U$ 1.000.000 more?" "No, it was an error from G in Development")
:) ).
It worked fine until somebody used a different language OS... and some strange quantities were recorded, one slipped all the way through the process and a confused customer received a bill for 17.000.000 local currency (about U$ 1.000.000) . I fixed it by using the CultureInfo, etc..
I'm sure there are better ways and good practices, but keep in mind that where I work we don't even have testing, so I guess I'm getting sloppy. If someone wants to give advice, go ahead, I'll appreciate it (or at least should
There are three kinds of lies: lies, damned lies, and statistics.
Doing math with strings will guarantee your code a place on the front page of thedailywtf.com
This is not a representation issue. It is a project management and testing issue.
...it's worth clarifying whether they're using the decimal or comma convention in the summary itself!
Yep the submitter got it wrong. Given that he is posting in English, to an American website, it makes no sense to use the comma as the decimal separator and the period as the thousands separator (unless the idea was to intentionally cause confusion to prove the point).
With a few exceptions (e.g. South Africa), the rule of thumb seems to be that if you're using English, you use "." as the decimal separator.
Wikipedia has a very long article on these things http://en.wikipedia.org/wiki/Decimal_separator, but most interesting is the diagram showing which countries use which. I found it surprising how many use "," as the decimal point. http://en.wikipedia.org/wiki/File:DecimalSeparator.png
In reality an ATM doesn't need any decimal point. Unless there's some ATM out there that dispenses anything coins.
I've never understood why every ATM that I've ever used that dispensed $20 bills made me type in the 00 cents each and every time.
The software should have gone through several
INDEPENDENT code reviews. The bank simply has
not done a proper job. The losses should come
directly from this bank's bottom line. The one
who pinched pennies to get this software rolled
out, needs to be terminated.
This is just one of the many pitfalls when trying to localize your software.
Does Your Code Pass The Turkey Test?
Anyway, the International Bureau of Weights and Measures, in their22nd General Conference, decided that:
"the dot (point on the line) [is used] as the decimal marker in all the English language versions of its publications, including the English text of the SI Brochure (the definitive international reference on the SI), with the comma (on the line) remaining the decimal marker in all of its French language publications"
And from the 7th General Conference which was held in 1948:
"Numbers may be divided in groups of three in order to facilitate reading; neither dots nor commas are ever inserted in the spaces between groups."
Those familiar with scientific publications will also not that those recommandations are enforced by editors, even american ones, because those aim an international audience. Now, you do what you want inside your country.