Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Moving Decimal Bug Loses Money

CmdrTaco posted more than 4 years ago | from the test-your-code-people dept.

It's funny.  Laugh. 420

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

cancel ×

420 comments

Sorry! There are no comments related to the filter you selected.

No, no, that's just a voluntary tax payment... (-1, Troll)

DamonHD (794830) | more than 4 years ago | (#30226148)

(FIRST?)

B^>

Rgds

Damon

This just in (0)

Anonymous Coward | more than 4 years ago | (#30226154)

Small errors, such as TYPOS can cause big problems.

You mean 11,500 Euro (4, Informative)

Chrisq (894406) | more than 4 years ago | (#30226162)

You mean 11,500 Euro as 11.500 Euro.

Re:You mean 11,500 Euro (2)

MadMatr07 (1278450) | more than 4 years ago | (#30226240)

You know, I really never understood the decimal point being a comma. But then again, I'm an American.

Re:You mean 11,500 Euro (1, Informative)

ls671 (1122017) | more than 4 years ago | (#30226402)

I am not American, but I find the comma used as decimal point stupid and silly although I should be using it in my native locale.

Re:You mean 11,500 Euro (1)

jhol13 (1087781) | more than 4 years ago | (#30226628)

Thankfully many applications, especially web based, allow both comma and period. Not all - and then there is CSV ...

Situation was worse some time ago in Firefox/Linux, it made some weird character from the numerical keyboard comma (Finnish keyboard). That made banking annoying.

Re:You mean 11,500 Euro (1)

dzfoo (772245) | more than 4 years ago | (#30226708)

Perhaps if it were called a "decimal comma" it'll make more sense.

        -dZ.

Re:You mean 11,500 Euro (1)

camcorder (759720) | more than 4 years ago | (#30226426)

Nobody makes decimal point a comma. Decimal point is always a point. It's just that there's not term like decimal point in places where comma is used as "decimal separator".

Re:You mean 11,500 Euro (5, Funny)

Kartoffel (30238) | more than 4 years ago | (#30226526)

It's still a decimal point. Europeans just put a little tail on it to be fancy.

Re:You mean 11,500 Euro (4, Insightful)

Razalhague (1497249) | more than 4 years ago | (#30226270)

No, I think he means 115 Euro as 11500 Euro (thousands separators are more trouble than they're worth).

Re:You mean 11,500 Euro (0)

Anonymous Coward | more than 4 years ago | (#30226784)

No, they do mean 115,00 as 11.500[,00] ...

Obligatory Office Space (5, Funny)

dkleinsc (563838) | more than 4 years ago | (#30226166)

I always do that, I mess up some mundane detail!

Re:Obligatory Office Space (0)

Anonymous Coward | more than 4 years ago | (#30226464)

It's not some mundane detail Michael!!

Re:Obligatory Office Space (1)

bytethese (1372715) | more than 4 years ago | (#30226488)

It's not some mundane detail Michael!

Apparently I got logged off with my last comment, also not a mundane detail!

God Bless the USA! (5, Funny)

jellomizer (103300) | more than 4 years ago | (#30226172)

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!

Re:God Bless the USA! (0)

Anonymous Coward | more than 4 years ago | (#30226262)

The Europeans didn't know that Intel/AMD design their ALU's to be error proof if you use periods to indicate decimals.

Re:God Bless the USA! (0)

Anonymous Coward | more than 4 years ago | (#30226284)

As with most things, the USA is still using the same system as the UK, and it's only mainland Europe that has them reversed. I'm not sure 'God' has anything to do with it.

Re:God Bless the USA! (5, Funny)

benwiggy (1262536) | more than 4 years ago | (#30226332)

I think you mean "God Save the Queen". We (the British) gave you the correct method for decimals before we decided to let you have the place. You've managed to pick up a few bad habits from the French, such as driving on the right.

But apart from that, you're doing quite well.

(For the benefit of Australians, this is humour, not flamebait.)

Re:God Bless the USA! (4, Funny)

Anonymous Coward | more than 4 years ago | (#30226344)

I think you mean "God Save the Queen". We (the British) gave you the correct method for decimals before we decided to let you have the place. You've managed to pick up a few bad habits from the French, such as driving on the right.

But apart from that, you're doing quite well.

(For the benefit of Australians, this is humour, not flamebait.)

Oh be quiet, you whinging pommy bastard.

Re:God Bless the USA! (0)

Anonymous Coward | more than 4 years ago | (#30226528)

Anon has no country, so Anon doesn't care what county is insulted.
Anon laughs at all countries, as they are all dumb pieces of shit that just try to make trouble for Anon.

Re:God Bless the USA! (4, Funny)

Kartoffel (30238) | more than 4 years ago | (#30226556)

Australians seem to be doing even better than Americans, then. They still drive on the proper side of the road, although they measure distances in kilometers rather than miles as god and the queen intended.

Well at least Australia is doing better than Canada. Those poor sods drive on the wrong side *and* use the metric system on their roads.

Re:God Bless the USA! (-1, Flamebait)

sopssa (1498795) | more than 4 years ago | (#30226706)

Wrong side? Right hand traffic is the correct side and is so in most of the countries in world [wikipedia.org] . UK, Australia and India are the only big counties driving on wrong side of road and that causes dangers if visiting there or their people visit elsewhere.

It makes a lot more sense to change to right hand traffic in those countries than in all the others.

Re:God Bless the USA! (1)

L3370 (1421413) | more than 4 years ago | (#30226770)

don't forget japan. :)

Re:God Bless the USA! (1)

Firehed (942385) | more than 4 years ago | (#30226756)

Did you just inadvertently congratulate America for not using the Metric system? Shame on you! It makes 10 weather so uncomfortable!

Re:God Bless the USA! (1)

saforrest (184929) | more than 4 years ago | (#30226798)

Well at least Australia is doing better than Canada. Those poor sods drive on the wrong side *and* use the metric system on their roads.

And on top of that we have French as one of our official languages.

Nous sommes vraiment des moutons perdus!

Re:God Bless the USA! (1)

camperdave (969942) | more than 4 years ago | (#30226808)

Hey! We have to distinguish ourselves from Americans somehow. Using Canadian Tire money just wasn't cutting it.

Re:God Bless the USA! (4, Interesting)

Yvanhoe (564877) | more than 4 years ago | (#30226382)

Do you know the nightmarish hell that is an Excel localized in French while being part of an international team ? Copy-paste of the same data using Excel EN or Excel FR will result in either 115.5 or 115,5 leading to interesting bugs to track...

Re:God Bless the USA! (2, Interesting)

teg (97890) | more than 4 years ago | (#30226562)

Not only that, the function names are localized too IIRC - meaning that a simple sum() doesn't work, as you should be using summ(). Copy, paste, and just plain sharing internationally doesn't work too well.

Re:God Bless the USA! (0)

Anonymous Coward | more than 4 years ago | (#30226650)

Do you know the nightmarish hell that is an Excel localized in French while being part of an international team ? Copy-paste of the same data using Excel EN or Excel FR will result in either 115.5 or 115,5 leading to interesting bugs to track...

Did you know that .csv files are different too? Excel in French expects .csv files to have fields separated by semicolons.

Re:God Bless the USA! (5, Insightful)

AP31R0N (723649) | more than 4 years ago | (#30226436)

Our method makes more sense. A sentence can have more commas than periods. Generally sentences have just one period (i'm distinguishing between dots and periods here). A period is a more solid division than a comma. It makes more sense to use the stronger punctuation as the mark between whole and fraction.

i'll grant that metric is better than imperial, but i think this is one thing where we have the better idea.

It's my opinion and it's worth every penny you paid for it.

Re:God Bless the USA! (1, Informative)

Anonymous Coward | more than 4 years ago | (#30226626)

Your post makes no sense. The only thing that makes sense is using spaces for thousands separator. That's also the international standard.

Re:God Bless the USA! (1)

Tim C (15259) | more than 4 years ago | (#30226722)

i'll grant that metric is better than imperial, but i think this is one thing where we have the better idea.

Using a comma or a period for the decimal separator is not a metric vs imperial issue, neither system mandates the character used for that.

Re:God Bless the USA! (0)

Anonymous Coward | more than 4 years ago | (#30226730)

URLs have more periods than commas and it seems to work fine. Yet URLs are in words and you are trying to apply this logic to numbers.

Re:God Bless the USA! (4, Funny)

domulys (1431537) | more than 4 years ago | (#30226450)

It is obvious to the most simple minded that Loki is of an inferior breed.

I am black on the right side. Loki is WHITE on the right side, all of his people are white on the right side!

1,00st post! (4, Funny)

Anonymous Coward | more than 4 years ago | (#30226182)

1,00st post!

Re:1,00st post! (2, Funny)

sopssa (1498795) | more than 4 years ago | (#30226514)

Dear Mr. Anonymous Coward,

Your thousand separator is one off. Seeing your post is not the first post, I must assume you meant 100st post, because it will be dropped around there soon enough. In either case, you failed.

Best regards,
Your loving wife

Re:1,00st post! (0)

Anonymous Coward | more than 4 years ago | (#30226584)

Whoosh.

Re:1,00st post! (0)

Anonymous Coward | more than 4 years ago | (#30226692)

Whoosh!

Re:1,00st post! (2, Funny)

cheftw (996831) | more than 4 years ago | (#30226780)

I must assume you meant 100st post

That's about 630kg.

Pretty heavy for a post.

Not helping! (1)

Sockatume (732728) | more than 4 years ago | (#30226206)

Given the subject, surely the submitter can see why it's worth clarifying whether they're using the decimal or comma convention in the summary itself!

For the most part. (1)

jellomizer (103300) | more than 4 years ago | (#30226210)

Most programs I have seen they don't allow you to type in thousands separator. If they are fancy they will display it to you for in the program when you type in the number. Otherwise it will not show... And for God sake why would you want to store the number as a string any ways?

Re:For the most part. (3, Funny)

imgod2u (812837) | more than 4 years ago | (#30226264)

It's like the little penny tray. The pennies are for everyone. And we're just taking fractions of a penny here.

Re:For the most part. (4, Funny)

qwijibo (101731) | more than 4 years ago | (#30226434)

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.

Re:For the most part. (1)

Zantac69 (1331461) | more than 4 years ago | (#30226534)

I don't know what happened, I must have missed a decimal point or something...

Re:For the most part. (1, Troll)

zwei2stein (782480) | more than 4 years ago | (#30226296)

Int-like dataypes have hard limit of 2^32 or 64 or even more.

Eventually you simply want something bigger. And you also want to use somethign that can work well with XML schemans and several other systems. You simply have to use string as your other option is 32 bit int.

Also, String unlike Float does not loose precission. A lot slower, but precise.

Re:For the most part. (1, Funny)

Anonymous Coward | more than 4 years ago | (#30226338)

You need a number over 2^32 FOR AN ATM?!
Is this related to the need in Zimbabwe for ATMs to distribute $1,000,000,000,000 bills?

Re:For the most part. (1)

zwei2stein (782480) | more than 4 years ago | (#30226746)

actually, 2^32 might have range of 2,147,483,648, but in reality, last 3 digits need to be abused for currency fraction. And 2 million is not a lot money in some currencies. In Italian Lira, that is about ~ 2k dollars. Amount that is very reasonable to withdraw from ATM.

Re:For the most part. (4, Insightful)

sopssa (1498795) | more than 4 years ago | (#30226356)

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!

Re:For the most part. (1)

Megane (129182) | more than 4 years ago | (#30226594)

...unless you're using 10^12 = one billion and 10^9 = one milliard

In any case, it should be an integer number of pennies (or whatever they call the euro-cents), so you're going to have to keep your account under 184 quadrillion, or is that 184 billiard? (balls!)

Re:For the most part. (1)

31415926535897 (702314) | more than 4 years ago | (#30226760)

This could be true in Zimbabwe.

Re:For the most part. (5, Insightful)

radish (98371) | more than 4 years ago | (#30226476)

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.

Re:For the most part. (1)

Lumpy (12016) | more than 4 years ago | (#30226610)

How about using a standard like IEEE floating point Hex? I can store Gigantorus numbers in tiny spaces with that.

42F9F8BC71118F14 = 456,897,665,767,665.25
IEEE Floating point in Hexadecimal is a standard that anyone that has a clue about computers or data storage should already know about. The fact they were storing numbers as strings means their programmers are complete uneducated noobs.

That's what you get when you outsource your software to the cheapest contractor.

Re:For the most part. (0)

Anonymous Coward | more than 4 years ago | (#30226806)

How about using a standard like IEEE floating point Hex? I can store Gigantorus numbers in tiny spaces with that.

42F9F8BC71118F14 = 456,897,665,767,665.25
IEEE Floating point in Hexadecimal is a standard that anyone that has a clue about computers or data storage should already know about. The fact they were storing numbers as strings means their programmers are complete uneducated noobs.

That's what you get when you outsource your software to the cheapest contractor.

But for money you just want fixed point. No sense in wasting all that precision past two decimal places!

Re:For the most part. (2, Insightful)

The MAZZTer (911996) | more than 4 years ago | (#30226640)

Doing math with strings will guarantee your code a place on the front page of thedailywtf.com

Re:For the most part. (1)

Nadaka (224565) | more than 4 years ago | (#30226530)

a 64 bit long has more than enough space to handle every currency in the world (except possibly hyper-inflationary Zimbabwe) to a tiny fraction of a penny. Even then, there are data structures that offer arbitrary precision and arbitrary ranges of values that are far more efficient than any string manipulation. In most cases, you are going to be converting the string back to a number for real math anyway. Hell even cobol handles numbers better than strings.

I won't even go into the rediculousness of using xml for data storage and retrieval for high throughput systems.

Re:For the most part. (1)

Duhavid (677874) | more than 4 years ago | (#30226590)

BCD is an option.

Re:For the most part. (2, Informative)

sopssa (1498795) | more than 4 years ago | (#30226302)

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

Re:For the most part. (1, Interesting)

Anonymous Coward | more than 4 years ago | (#30226410)

Until you need to list many numbers in sequence. Is 153 987 182 991 equal to 153,987,182,991 or is it 153, 987, 182, & 991 or maybe 153,987 & 182,991?

Re:For the most part. (1)

Razalhague (1497249) | more than 4 years ago | (#30226758)

Then you use a list separator, dumbass. Preferably a semicolon so there's no confusion.

Re:For the most part. (0)

Anonymous Coward | more than 4 years ago | (#30226454)

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

Space can be just as confusing as comma or period. I'm going to revolutionize banking and suggest we move in a new direction. I'm going to take the offensive on confusion and suggest we use 0 to deliminate/separate groupings of numbers.

Re:For the most part. (1)

dontclapthrowmoney (1534613) | more than 4 years ago | (#30226482)

Not a horrible suggestion for some situations, but the space just doesn't work for me... it looks like two different numbers, especially if you're writing a list of numbers next each other - do you use comma then?

50 006.49, 14 032.45, 200 154 209.45,

Did I miss a comma and one of the numbers is also missing the .00, did I miss a decimal point somewhere and the decimal is more precise, or is the last number just really large?

Not in favor of the comma separators in large numbers, it is not universally understood, so don't do it.

50006.49 14032.45 200154209.45

I think this number sequence would be interpreted correctly in most places, most people (even people who normally use decimal commas) would understand what the decimal point represents here.

Re:For the most part. (1)

dapaua (1548739) | more than 4 years ago | (#30226724)

I (and many friends) use apostrophe as decimal separator in handwriiteing, so it is:
50006'49 , 14032'45 , 200154209'45 .

Sounds like a hacker got a decimal in the wrong pl (0)

Anonymous Coward | more than 4 years ago | (#30226218)

Sounds like a hacker got a decimal in the wrong place and now they need to unload the money some where fast they have try talking to drug dealers about money laundering.

Good to be a programmer (4, Insightful)

Anonymous Coward | more than 4 years ago | (#30226258)

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.

Re:Good to be a programmer (0)

Anonymous Coward | more than 4 years ago | (#30226678)

While there's no license to be revoked, I think you're being naive if you really believe nobody will get fired for this.

Re:Good to be a programmer (1)

wisty (1335733) | more than 4 years ago | (#30226778)

"Real engineers" have all sorts of cock-ups. Look at cost-overruns in the overage one-off construction project - they are similar to overruns in software projects.

Safety-critical hardware has all sorts of redundancy. I daresay that software could have a safety factor built in - you could duplicate the code 5 times using separate software teams and different methodologies, then weed out the incorrect results, but who would pay for all that waste? Even aircraft engineers have about 1% safety margins. Software engineers usually have 0%. Do you wonder why it breaks occasionally?

That's why it is called a floating point. (0)

Anonymous Coward | more than 4 years ago | (#30226306)

Duh.

Mundane detail (1)

nitsew (991812) | more than 4 years ago | (#30226352)

Ok! Ok! I must have, I must have put a decimal point in the wrong place or something. Shit. I always do that. I always mess up some mundane detail.

Back to Roman numerals (1)

ewg (158266) | more than 4 years ago | (#30226384)

I bet you LXXVII bucks this would not have happened with Roman numerals. That's what they get for upgrading a perfectly good numeration system.

Periods and commas. (3, Insightful)

MaWeiTao (908546) | more than 4 years ago | (#30226394)

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.

Re:Periods and commas. (0)

Anonymous Coward | more than 4 years ago | (#30226472)

Gramatically, I think it makes more sense the European way:

Fifteen dollars, eleven cents.

OR:

Fifteen dollars. Eleven cents,

Re:Periods and commas. (0)

Anonymous Coward | more than 4 years ago | (#30226532)

Ah, but what makes more sense here?

One thousand, one hundred dollars

OR

One thousand. One hundred dollars

Re:Periods and commas. (1)

Sergey23 (1055324) | more than 4 years ago | (#30226576)

The latter is the European way. Hence, you're agreeing with the parent post.

Re:Periods and commas. (5, Insightful)

mccalli (323026) | more than 4 years ago | (#30226510)

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?

See, that argument doesn't make 'sense' either. If a comma is a separator, why not use it to separate decimals? Answer: no reason, it is completely and utterly arbitrary. You're arguing that the point of view you're used to is somehow intrinsicly 'right' - it isn't, it's just usage and custom.

It would be like writing a sentence this way:

Somehow, I suspect mainland Europe knows what it's like to write a sentence including thousands sperators and decimal separators...

I'm British - I use "," to separate thousands and "." to separate decimals, but that doesn't make me 'right' - it really is just usage and custom, there isn't anything to really recommend one way over the other.

Cheers,
Ian

Re:Periods and commas. (1)

L4t3r4lu5 (1216702) | more than 4 years ago | (#30226676)

No no, I'm English too. You're definitely right on this one.

Spiffing!

Re:Periods and commas. (1)

Grygus (1143095) | more than 4 years ago | (#30226748)

In matters of custom, the more universally recognized method is the right one. Everyone knows what 1,054.65 means. Some people do not know what the hell 12,56 is supposed to be. Since confusion in financial transactions is good for nobody at all, the correct custom is in fact the former. If you want to implement a new worldwide custom then that's fine but I suspect you will need a very good justification and not simply the desire to do something new.

Re:Periods and commas. (1)

fractic (1178341) | more than 4 years ago | (#30226754)

I'm British - I use "," to separate thousands and "." to separate decimals, but that doesn't make me 'right' - it really is just usage and custom, there isn't anything to really recommend one way over the other.
 

Actually there is. The reason why a comma is used as a decimal separator in some places is the following. The decimal separator is more important
that the thousands separator, a misplaced thousands separator doesn't matter since it has no effect on the value. Now a speck of ink is more easily mistaken for a dot than a comma. It would be bad to mistake a speck of ink for a decimal separator.

Some people have argued that because the dot is more important for sentence structure it should also be used for the more important decimal separator. However this isn't a very strong argument since there is no reason to use grammar rules for the notation of numbers.

That said, personally I use a dot since I need the comma to separate lists of numbers (e.g. 1.2, 1.3, 1.4 ) and the comma notation for lists is almost
universal.

Re:Periods and commas. (1)

EvilIdler (21087) | more than 4 years ago | (#30226544)

I don't think this has anything to do with us using commas for decimal space at all. It is perfectly clear to us, despite it not being clear to your untrained mind ;)

My bank uses spaces to separate thousands and a comma for the decimal spot. If a sentence ends with a sum of money, we won't have two full stops in a row, which I'd find harder to read than "1 324 299,53" at the end of a sentence.

Re:Periods and commas. (0)

Anonymous Coward | more than 4 years ago | (#30226554)

Europeans don't "swap periods and commas". They all use the comma as decimal separator, and some of them use periods as thousands separator against standards. Thousands should always be separated with a space. Either periods or commas make no sense for separating thousands, as this separation does not *mean* anything, it is only here to make big numbers easier to read.

Re:Periods and commas. (0)

Anonymous Coward | more than 4 years ago | (#30226568)

Well, guess what? We usually do not use the point at all. In common usage, 1000's are seperated by spaces : 10 000,00 Euro, to give an example.
Now why the comma? Because the number does not end at the "decimal seperator", and the comma is much easier to actually read.

10 000,00
10 000.00

Pretty obvious, yes?

Re:Periods and commas. (1)

Monkeedude1212 (1560403) | more than 4 years ago | (#30226740)

You fail to Recognise that seperators in numbers are completely irrelevant to English Grammar.

Similarily, if I say

"I would like to buy that item for $2.50 please."

That there is a period in the middle of the sentence. It's one thing that has bugged me for a long time. But the point is that Period and comma's are interchangable in math. After all, they are just symbols applied to a concept. I think the best way to describe it would be like saying the same rules for syntax that apply to English do not apply to Spanish or French. Similarily, you can't apply those same rules to Mathematics. They are their own language.

Re:Periods and commas. (0)

Anonymous Coward | more than 4 years ago | (#30226794)

Europeans did not make the swap, americans did...

Or are you not aware that Europe used decimals way before the US existed ?

At least they roll back without a law suit (0)

Anonymous Coward | more than 4 years ago | (#30226420)

At least they roll this back immediately. Here in the US of A they would wait for a class action law suit to develop and then offer a settlement that leaves their customers with pennies on the dollar.

This is stupid. (3, Insightful)

BlueKitties (1541613) | more than 4 years ago | (#30226440)

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.

Re:This is stupid. (0)

Anonymous Coward | more than 4 years ago | (#30226802)

Think of it as the decimal analog to the filepath directory separator, for platform-interoperable code - Windows uses a character which is used as the single-character escape in Unix-based string processing and C runtime functions. It's not that it's difficult to figure out how to workaround, it's just ensuring that you have these damn workarounds and conditional blocks in all the right places. Typically, you'll get most of them right for you ship, but a few will be reported as bugs from the field, and you're never quite certain you've got them all.

Bizzarro Superman (2, Funny)

Kartoffel (30238) | more than 4 years ago | (#30226442)

It's just like in Superman III, but backwards!

Decimal and Thousands separators (1)

Razalhague (1497249) | more than 4 years ago | (#30226468)

I really wish it could be standardized with the decimal separator being either a comma or a period and the thousands separator being neither.

Re:Decimal and Thousands separators (1)

SeeSchloss (886510) | more than 4 years ago | (#30226698)

Well, it has been standardised for a long time. Decimal separator is either a comma or a period (with a comma being recommended) and the thousands separator is either nothing or a space.

Re:Decimal and Thousands separators (1)

welshie (796807) | more than 4 years ago | (#30226804)

and don't get be started on the correct formatting of telephone numbers, and how Excel (and Excel-compatible) spreadsheets tend to wreck telephone numbers by attempting to parse them as floating point numbers.

Powers-of-ten Information Biases (0)

Anonymous Coward | more than 4 years ago | (#30226486)

This is called a "power-of-ten information bias." The problem was described almost 20 years ago in the Management Information Systems Quarterly, Vol. 14, No. 1, March 1990, pp. 63-77.

Happened to me recently (2, Interesting)

Acer500 (846698) | more than 4 years ago | (#30226538)

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.

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

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

Windows XP (1)

Krneki (1192201) | more than 4 years ago | (#30226630)

The whole system is probably running on Windows XP Home and someone must have changed the regional settings to Italy so he can install some Italian crap on it.

P.S: Just trolling. :)

Oblig. Office Space (1, Redundant)

Powys (1274816) | more than 4 years ago | (#30226672)

“I always do that. I always mess up some mundane detail.”

In Socialist Italy...... (1)

benwiggy (1262536) | more than 4 years ago | (#30226702)

In Socialist Italy, the period separates you into groups of thousands!

testing is the issue (4, Insightful)

maxwells daemon (105725) | more than 4 years ago | (#30226720)

This is not a representation issue. It is a project management and testing issue.

This Could Never Happen In The U.S. (1)

Petersko (564140) | more than 4 years ago | (#30226728)

People in the U.S. with that kind of cash are considered so rich that they don't go down to the post office themselves.

That's what LC_NUMERIC is for (1)

gzipped_tar (1151931) | more than 4 years ago | (#30226732)

Use it or lose it. Duh.

Italian Office Space ? (1)

Beretta Vexe (535187) | more than 4 years ago | (#30226744)

Alright so when the sub routine compounds the interest is uses all these extra decimal places that just get rounded off. So we simplified the whole thing, we rounded them all down, drop the remainder into an account we opened.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>