• BluePlateSpecial (unregistered)

    @Brian White

    Yeah I actually took a class on stuff like that. I don't deal with figures that have to be exactly correct so I didn't think about that. Especially the poster that talked about 0.1 not being able to be represented in binary. I remember that being an example in the class. So the idea the programmer was using was correct, just bad implementation

  • Tim (unregistered) in reply to samiam

    You know, I stared at that, and wondered to myself, that sounds SO familiar....

    Then I felt dumb.

  • (cs) in reply to Gieron
    Gieron:
    Overloading the + character to mean both arithmetic addition and string concatenation in any language that doesn't force you to declare variables as either int or string has always stroked me as a really bad idea.

    Perl is one of the few script languages that does this correctly, where string concatenation is done with ..

    (note that the second dot is the end of the sentence)

    php also uses period as the strcat oper

  • Troy (unregistered)

    The real WTF is the car payment. $400/month? Ouch!

    http://www.daveramsey.com/etc/cms/don%27t_let_your_car_own_you_9565.htmlc

  • pong (unregistered)

    TRWTF is how many people responded after merely reading the bottom text and not using their brains.

  • Anon (unregistered) in reply to Clark S
    Clark S:
    The company is the in-house financing agent for a brand of inexpensive import automobiles that may-or-may-not have an 'S', 'Z' and 'K' in the make.

    $400/month is inexpensive?

  • Brendan (unregistered) in reply to Anon
    Anon:
    $400/month is inexpensive?

    $400/month for 3 months would be extremely inexpensive. $400/month for 26 years would be very expensive...

  • (cs) in reply to DWalker59
    DWalker59:
    The Java-implemented drop-down box lets me pick one of the two cards... but they are both named "blah blah blah blah ending in xxxx", and only the part that says "blah blah blah blah end" shows up in the drop-down.
    I thought we were talking about the implementation of ECMAscript known as Javascript -- or is that what you meant by "Java-implemented"? You do realise they're different things, right?

    Now, if you knew what you were doing, you could write your own Javascript front-end, based on theirs, and find out if it's the Javascript that's broken, or the back-end that's serving the truncated identifier.

  • moz (unregistered) in reply to Clark S
    Clark S:
    As for the JavaScript calculations, I have an attempt at a simple solution:
    for(var j=0; j<inputs.length; j++) {
             if(inputs[j].name != 'totalPayment' && inputs[j].value.trim() != '') {
                charges = parseFloat(inputs[j].value, 10) * 100;
                total += Math.floor(charges);
             }
          }
    total /= 100;
    
    oForm.totalPayment.value = total.toFixed(2);</pre>Now rip me to shreds.
    I wouldn't do that, as I've only just cleaned these shoes. I would avoid turning inputs[i].value into a float when you can just squash the decimal point and read it as in integer in the first place.
    Clark S:
    Of course, the lady on the phone really didn't care about any of this, and practically ignored what I had to say, like someone with their hand over their ears yelling "LALALALALALA I CAN'T HEAR YOU." Didn't even bother saying something like "sir, there's no way I can reach the programmers" or what-not.
    But of course. She needs those $10 charges to feed her family.
  • AshG (unregistered) in reply to BluePlateSpecial
    BluePlateSpecial:
    @Kermos and Anguirel

    Guess it's good I never work with money transactions then! I didn't think it made that big of difference but I could see how being off by a little could add up over time. I still think the person could have made the code a lot simpler to handle such a simple task (as some of the comments mentioned). I mean I have seen a lot more complex js but given the end result, that has to be a better way.

    Holy Crap! If they calculate a fraction of a penny wrong, over a 5-year loan that will result in customer's loss of 60 pennies! Holy Crap, fix it! As in, NOW!

  • Sylver (unregistered) in reply to Kermos
    Kermos:
    Ok, WTF??
    1. This is a transaction involving money
    2. Why is the total calculated CLIENT side with javascript?
    3. Why does the word 'float' appear anywhere when dealing with money?
    4. Why the flying fuck are they using string concatenation to do this? ...

    I agree. The main WTF here is that they are doing it client-side. Other than that, well it's just a mistake and I am sure we all do some on occasion.

  • Dilberto (unregistered) in reply to Downfall

    Would you trust that system to take the correct amount out of your bank account? I wouldn't.

  • Sylver (unregistered) in reply to AshG
    AshG:
    BluePlateSpecial:
    @Kermos and Anguirel

    Guess it's good I never work with money transactions then! I didn't think it made that big of difference but I could see how being off by a little could add up over time. I still think the person could have made the code a lot simpler to handle such a simple task (as some of the comments mentioned). I mean I have seen a lot more complex js but given the end result, that has to be a better way.

    Holy Crap! If they calculate a fraction of a penny wrong, over a 5-year loan that will result in customer's loss of 60 pennies! Holy Crap, fix it! As in, NOW!

    Your bank must love you! Try and think a bit one of these days. A penny off in the balance of an account. Not much of a problem (although 60 pennies x 20M customers = 12M, a decent chunk of change).

    Now, what if the rounding error is applied to the monthly interest rate? Or if we stop being trivial, what if it occurs on the exchange rates where each transaction weights billions of USD? Would you like to pay the difference?

    You can't afford this kind of lazy rounding if you deal with financial data. Period.

  • tation (unregistered) in reply to Sylver
    Sylver:
    AshG:
    BluePlateSpecial:
    @Kermos and Anguirel

    Guess it's good I never work with money transactions then! I didn't think it made that big of difference but I could see how being off by a little could add up over time. I still think the person could have made the code a lot simpler to handle such a simple task (as some of the comments mentioned). I mean I have seen a lot more complex js but given the end result, that has to be a better way.

    Holy Crap! If they calculate a fraction of a penny wrong, over a 5-year loan that will result in customer's loss of 60 pennies! Holy Crap, fix it! As in, NOW!

    Your bank must love you! Try and think a bit one of these days. A penny off in the balance of an account. Not much of a problem (although 60 pennies x 20M customers = 12M, a decent chunk of change).

    Now, what if the rounding error is applied to the monthly interest rate? Or if we stop being trivial, what if it occurs on the exchange rates where each transaction weights billions of USD? Would you like to pay the difference?

    You can't afford this kind of lazy rounding if you deal with financial data. Period.

    Not to mention the legal requirements in the playing with money field. Doing on the fly rendering is perfectly fine with having a few decimals wrong, most people wont see it anyways. Messing with money? Now that is quite different. ;) Lots of bean counters would rip your company to shreds for being lax with those calculations.

  • k1 (unregistered) in reply to Sylver
    Sylver:
    The main WTF here is that they are doing it client-side.
    I don't know... Probably the client-side sum is only for reference for the customer, a sort of preview, the real calculation made on the server.
    Sylver:
    Other than that, well it's just a mistake and I am sure we all do some on occasion.
    That's right, but... we do some test on it, sometime just a quick common-case test, some other a thorough one. In the case of the article, well... :D
  • Boggle (unregistered) in reply to BluePlateSpecial
    BluePlateSpecial:
    At least she wasn't trying to sell you something. I called up tech support for my pc and basically was able to fix the problem myself while on the phone with someone whose every other word was "want to try Norton Antivirus?" I mean seriously solve my problem then you can start your sales pitch. My problem wasn't even related to a virus! I really think those hotlines should have an extension where you can reach a representative of the tech team responsible for the code (or management of). That why she could have just told you to hold on, transferred you, and then had you talk to someone who can look into it and maybe fix it. Seems perfectly reasonable to me but apparently they just want script readers. That reminds me of another time I called support for a credit card issue. After being transferred roughly 5 times to different people (none of which actually listened to my problem or else I would have been transferred correctly the first time), I finally told the person on the phone, "stop reading from a script and actually help me with this" (or something to that effect.) I eventually was told that my credit card account was closed, which is what I wanted to make sure of from the start. It took that many people to look up my account on the screen and tell me the status was indeed "closed." Geesh!

    Oh what a wonderful idea....Let's have customers talk directly to technical teams and tell them how they should have done theuir job. That won't cause any problems.

    (Quote Homer: "In case you can't tell I was being Sarcastic")

    It is not surprising that the helpline is so unhelpful - they don't really understand what the caller is rabitting on about. That said, you would hope enough calls complaining about a 10 fold increase in the bill would ultimately lead to an investigation.

    Allowing the caller to speak to a techo with his diagnosis is, however, not the answer - especially in this case where he was wrong anyway, the problem was not in applying the extra 0 (as a plethora of people have already stated).

  • Boggle (unregistered) in reply to Henning Makholm
    Henning Makholm:
    Clark S:
    As for the JavaScript calculations, I have an attempt at a simple solution:

    [code]for(var j=0; j<inputs.length; j++) { if(inputs[j].name != 'totalPayment' && inputs[j].value.trim() != '') { charges = parseFloat(inputs[j].value, 10) * 100; total += Math.floor(charges); } }

    Better add 0.5 before Math.floor. You wouldn't want to take the floor of 4902.999999999999982 due to rounding for an input of "49.03".

    (I'm not sure how likely this is to happen, given that the two rounding steps seeem to tend to cancel each other out for the few examples I tries -- but rounding to nearest has to be much easier than proving rigorously that this can NEVER happen).

    Wha?

    I didn't really follow your example (methinks you may have 'mfused yourself). Please explain this 0.5 again. There is not necessarily a need to round in this sort of an example, and I think it is common practice in many situations (where there is not a large string of calculations) to drop decimals lower than a cent.

  • Slightly facecious (unregistered) in reply to Sylver
    Sylver:
    AshG:
    BluePlateSpecial:
    @Kermos and Anguirel

    Guess it's good I never work with money transactions then! I didn't think it made that big of difference but I could see how being off by a little could add up over time. I still think the person could have made the code a lot simpler to handle such a simple task (as some of the comments mentioned). I mean I have seen a lot more complex js but given the end result, that has to be a better way.

    Holy Crap! If they calculate a fraction of a penny wrong, over a 5-year loan that will result in customer's loss of 60 pennies! Holy Crap, fix it! As in, NOW!

    Your bank must love you! Try and think a bit one of these days. A penny off in the balance of an account. Not much of a problem (although 60 pennies x 20M customers = 12M, a decent chunk of change).

    Now, what if the rounding error is applied to the monthly interest rate? Or if we stop being trivial, what if it occurs on the exchange rates where each transaction weights billions of USD? Would you like to pay the difference?

    You can't afford this kind of lazy rounding if you deal with financial data. Period.

    Who Can't afford it? You object that the bank makes a significant profit, even though most customers wouldn't care (or at least wouldn't notice) the 60c. Is this Ethical? No. Is that the question? No.

    The point I thought the OP was making, is that ripping one customer off 60 cents is hardly a critical problem. Most wouldn't notice, and many wouldn't care. The fact that the bank does this to 20M customers and makes $12M is irrelevant to the argument. I realise most peole hate banks (as do I), but the OP quite rightly points out that 60 cents is not (for most people) a significant problem (a minor inconvenience at best). The fact that the bank capitalises on this is a totally separate issue about ethics and fair trading.

  • (cs) in reply to Sylver
    Sylver:
    Kermos:
    Ok, WTF??
    1. This is a transaction involving money
    2. Why is the total calculated CLIENT side with javascript?
    3. Why does the word 'float' appear anywhere when dealing with money?
    4. Why the flying fuck are they using string concatenation to do this? ...

    I agree. The main WTF here is that they are doing it client-side. Other than that, well it's just a mistake and I am sure we all do some on occasion.

    I would expect that the client-side calculation is solely there for user feedback (though in that case it ought to be calculated when the input fields are changed, rather than requiring an extra mouse click).

    The code looks like the victim of shotgun debugging; there were bugs but no-one could figure out how to actually fix them, so instead there's this ongoing sequence of half-baked attempts at applying "workarounds" with the hope that these bugs will eventually cancel each other out (adding zero didn't convert it to a number; oh, wait, sometimes it has the string "undefined" in it; let's try to parse an integer out of it; but after we do the calculation we lost the decimal - how did we get it back last time?....).

  • (cs) in reply to Bim Job
    Bim Job:
    Sometimes I stare at really quite simple bits of Javascript (such as the one we're talking about) and wonder whether it's the language's fault that so many people spend so much time getting it so horribly wrong. It's OK as a toy functional language, but when you combine it with regular expressions and (Ghods forbid) the DOM, it rapidly becomes an invitation to a nightmare.

    Javascript? A functional language? Puh-leeze, tacking some pseudo-closures onto a basically imperative scripting language is a long stretch from functional programming...

  • Anon. (unregistered) in reply to Boggle
    Boggle:
    I didn't really follow your example (methinks you may have 'mfused yourself). Please explain this 0.5 again. There is not necessarily a need to round in this sort of an example, and I think it is common practice in many situations (where there is not a large string of calculations) to drop decimals lower than a cent.

    Suppose that, at the situation just before we round, the value is supposed to 4903.

    Further suppose that the floating-point representation currently being used works out at around 4902.9999997

    If you always floor the value, you'll end up knocking a cent off the value.

  • Sylver (unregistered) in reply to Slightly facecious
    Slightly facecious:
    Sylver:
    AshG:
    Holy Crap! If they calculate a fraction of a penny wrong, over a 5-year loan that will result in customer's loss of 60 pennies! Holy Crap, fix it! As in, NOW!

    Your bank must love you! Try and think a bit one of these days. A penny off in the balance of an account. Not much of a problem (although 60 pennies x 20M customers = 12M, a decent chunk of change).

    Now, what if the rounding error is applied to the monthly interest rate? Or if we stop being trivial, what if it occurs on the exchange rates where each transaction weights billions of USD? Would you like to pay the difference?

    You can't afford this kind of lazy rounding if you deal with financial data. Period.

    Who Can't afford it? You object that the bank makes a significant profit, even though most customers wouldn't care (or at least wouldn't notice) the 60c. Is this Ethical? No. Is that the question? No.

    The point I thought the OP was making, is that ripping one customer off 60 cents is hardly a critical problem. Most wouldn't notice, and many wouldn't care. The fact that the bank does this to 20M customers and makes $12M is irrelevant to the argument. I realise most peole hate banks (as do I), but the OP quite rightly points out that 60 cents is not (for most people) a significant problem (a minor inconvenience at best). The fact that the bank capitalises on this is a totally separate issue about ethics and fair trading.

    Read again and try to understand the issue here. The problem isn't the 60 cts. That 60 cts figure was a number AshG pulled out of his ***, to make the point that it didn't matter.

    The problem is, it does matter. If you use floats with money transactions, you are in for trouble, and probably a lot more than just 60 cts a piece. Depending where the float was used, the difference could be billions of dollars. And as a programmer, you can't afford this kind of sloppiness.

    Further, you assume that the rounding error would be in favor of the bank. What if it is the other way around? What if the bank is missing 12M and that after careful investigation it turns out that your sloppy rounding is responsible for that loss. So now the bank is suing your *** for 12M + damages...Do you still think it doesn't matter?

  • (cs) in reply to Boggle
    Boggle:
    I didn't really follow your example (methinks you may have 'mfused yourself). Please explain this 0.5 again. There is not necessarily a need to round in this sort of an example, and I think it is common practice in many situations (where there is not a large string of calculations) to drop decimals lower than a cent.
    You want to round to the nearest cent to eliminate any small errors the conversion to floating point might've caused.

    Those errors could be in either direction: 0.1 * 100 might end up either as 10.0000000000123 or as 9.9999999999876 (numbers pulled out of a hat, may not reflect actual floating-point calculations).

    Math.floor() in JavaScript does not round to the nearest integer -- it rounds down to the largest integer less than the input. This means that 9.9999999999876 rounds to 9, not 10.

    Adding 0.5 to the number corrects for this. Work it out in your head if you like: Math.floor(x + 0.5) returns 10 if x is between 9.5 and 10.5 (inclusive below, exclusive above).

  • (cs)

    It's hard enough trying to break through the fortress of support and into bug reporting when it's a company... Try doing it when it's a government department you work for. You'll probably not only be told there's no problem, you you'll probably be accused of causing it to start with.

  • Anon (unregistered) in reply to Brendan
    Brendan:
    Anon:
    $400/month is inexpensive?

    $400/month for 3 months would be extremely inexpensive. $400/month for 26 years would be very expensive...

    FTFA:

    "For three years, I've made my car payments on time and in full," Clark S. writes
  • AdT (unregistered) in reply to rfsmit
    rfsmit:
    I thought we were talking about the implementation of ECMAscript known as Javascript

    <nit>JavaScript is not an implementation of ECMAScript, it's an extended pseudostandard with ECMAScript at its core. There are numerous JavaScript implementations, for instance SquirrelFish (Safari / WebKit), SpiderMonkey (Mozilla), Carackan (Opera) and many others.</nit>

  • Anonymous (unregistered)

    Painfully amateurish.

  • Anonymous Cowherd (unregistered)

    It just goes to prove the old adage that when you have a problem, and you decide to solve it with a regular expression, you will suddenly find yourself with two problems.

  • Henning Makholm (unregistered) in reply to Anonymouse
    Anonymouse:
    Javascript? A functional language? Puh-leeze, tacking some pseudo-closures onto a basically imperative scripting language is a long stretch from functional programming...
    I've heard one of the designers of JavaScript describe it as basically Scheme with some added syntactic sugar to make it look vaguely like Java.

    It's all a matter of perspective -- variable assignment is just set!, objects are primitive associative arrays of closures (for methods) and values (for fields), and so forth.

    The way I understood that talk is that closures is one of the only things in the language that ISN'T pseudo.

    (Disclaimer: I have not read the formal ECMAScript specification).

  • Henning Makholm (unregistered) in reply to Henning Makholm
    Henning Makholm:
    I've heard one of the designers of JavaScript describe it as basically Scheme with some added syntactic sugar to make it look vaguely like Java.
    I think this was Brendan Eich's invited talk at ICFP 2005.
  • Henning Makholm (unregistered) in reply to Boggle
    Boggle:
    I didn't really follow your example (methinks you may have 'mfused yourself). Please explain this 0.5 again. There is not necessarily a need to round in this sort of an example,
    Yes there is. Here is a concrete example with IEEE-754 doubles:
    #include <stdio.h>
    #include <math.h>
    main() {
      union { double f; long long i; } u ;
      u.f = 255;        printf("%016llx %.17f\n",u.i, u.f);
      u.f /= 100;       printf("%016llx %.17f\n",u.i, u.f);
      u.f *= 100;       printf("%016llx %.17f\n",u.i, u.f);
      u.f = floor(u.f); printf("%016llx %.17f\n",u.i, u.f);
    }
    
    which prints
    406fe00000000000 255.00000000000000000
    4004666666666666 2.54999999999999982
    406fdfffffffffff 254.99999999999997158
    406fc00000000000 254.00000000000000000
    
  • (cs) in reply to Henning Makholm
    Henning Makholm:
    Anonymous Coward:
    The real problem is in the formatCharges() function. The regex is wrong.
    True, that's the BUG. But what makes it a WTF is something slightly different.

    Ignoring the questionable decision to do this on the client side, the programmer had the right idea: Convert everything to cents before doing arithmetic, to prevent rounding errors. The WTF is how he chose to covert to/from cents.

    From human-readable dollar amounts to cents, they chose string manipulation (and got it wrong), where it would be simpler just to let JavaScript interpret the original string as a float, multiply by 100 and then round to the nearest integer.

    From cents to human-readable dollars, they chose to use floating-point division to insert the decimal point, followed by complex string manipulation to correct for trailing zeroes being lost by the division. Here it would have been much simpler to stick with pure string manipulation to insert the decimal point.

    They used the right two techniques (arithmetic vs. string manipulation), but each for the wrong task!

    That's a good analysis! Seriously.

  • (cs) in reply to rfsmit
    rfsmit:
    DWalker59:
    The Java-implemented drop-down box lets me pick one of the two cards... but they are both named "blah blah blah blah ending in xxxx", and only the part that says "blah blah blah blah end" shows up in the drop-down.
    I thought we were talking about the implementation of ECMAscript known as Javascript -- or is that what you meant by "Java-implemented"? You do realise they're different things, right?

    Now, if you knew what you were doing, you could write your own Javascript front-end, based on theirs, and find out if it's the Javascript that's broken, or the back-end that's serving the truncated identifier.

    Well, I don't write Web code, so I can't write my own front end. It might not even BE Javascript, but I think it is. Too bad the dialog box looks wonky and isn't resizeable and isn't moveable.

  • (cs) in reply to Slightly facecious
    Slightly facecious:
    Sylver:
    AshG:
    BluePlateSpecial:
    @Kermos and Anguirel

    Guess it's good I never work with money transactions then! I didn't think it made that big of difference but I could see how being off by a little could add up over time. I still think the person could have made the code a lot simpler to handle such a simple task (as some of the comments mentioned). I mean I have seen a lot more complex js but given the end result, that has to be a better way.

    Holy Crap! If they calculate a fraction of a penny wrong, over a 5-year loan that will result in customer's loss of 60 pennies! Holy Crap, fix it! As in, NOW!

    Your bank must love you! Try and think a bit one of these days. A penny off in the balance of an account. Not much of a problem (although 60 pennies x 20M customers = 12M, a decent chunk of change).

    Now, what if the rounding error is applied to the monthly interest rate? Or if we stop being trivial, what if it occurs on the exchange rates where each transaction weights billions of USD? Would you like to pay the difference?

    You can't afford this kind of lazy rounding if you deal with financial data. Period.

    Who Can't afford it? You object that the bank makes a significant profit, even though most customers wouldn't care (or at least wouldn't notice) the 60c. Is this Ethical? No. Is that the question? No.

    The point I thought the OP was making, is that ripping one customer off 60 cents is hardly a critical problem. Most wouldn't notice, and many wouldn't care. The fact that the bank does this to 20M customers and makes $12M is irrelevant to the argument. I realise most peole hate banks (as do I), but the OP quite rightly points out that 60 cents is not (for most people) a significant problem (a minor inconvenience at best). The fact that the bank capitalises on this is a totally separate issue about ethics and fair trading.

    "Most wouldn't notice any many wouldn't care"? The bank regulators and state attorneys general would certainly care. Dealing with money has some legal ramifications.

  • EngleBart (unregistered) in reply to DWalker59
    DWalker59:
    Yes, but the REAL question is, if you pay $400.97 plus $49.03, do they credit you with a payment of $4500? That would be cool. Your car will be paid off soon.
    o Enter 10% of the value owed on your car.
    o Keep the late payment field filled out.
     (My mistake, your gain on the late payment)
    o Print a picture of their website.
    o Send in TWO, SEPARATE checks and demand that they
      credit your account according to their website.
      Copy a random trial attorney on the correspondence.
    o Your car is now paid off in one easy payment.
    o Call it "Cash from Flunkers"
  • AshG (unregistered) in reply to Sylver
    Sylver:
    Read again and try to understand the issue here. The problem isn't the 60 cts. That 60 cts figure was a number AshG pulled out of his ***, to make the point that it didn't matter.

    The problem is, it does matter. If you use floats with money transactions, you are in for trouble, and probably a lot more than just 60 cts a piece. Depending where the float was used, the difference could be billions of dollars. And as a programmer, you can't afford this kind of sloppiness.

    Further, you assume that the rounding error would be in favor of the bank. What if it is the other way around? What if the bank is missing 12M and that after careful investigation it turns out that your sloppy rounding is responsible for that loss. So now the bank is suing your *** for 12M + damages...Do you still think it doesn't matter?

    So you are saying your hand-crafted floating point math has better precision than that of the CPU. Let's see.

    Double data type offers you 15 digits. For the majority of money transactions such as purchases (100 bucks or less) this gives you 12 digits of precision, make it 11 since the last digit is always screwed up. It will take your system 10E11 transactions to make a 1 penny mistake.

    Now, speaking of billion-dollar transactions. 3 digits of precision. 1000 transactions, 12-digits each, and you are short 1 dollar.

    Once again, Holy crap!

  • Henning Makholm (unregistered) in reply to AshG
    AshG:
    Now, speaking of billion-dollar transactions. 3 digits of precision. 1000 transactions, 12-digits each, and you are short 1 dollar.

    Once again, Holy crap!

    Holy crap indeed. Even after 10 transitions you'll be an entire cent off. And that one cent could cost you tens of thousands of dollars.

    Have you ever worked with accountants or auditors? Those people will not yield until the missing penny has been accounted for, on the very reasonable theory that if the system forgets pennies for no known reason, the reason should be found before one day the same bug will lead to a million going missing.

    Doing exact arithmetic on integral numbers of cents is not difficult and therefore it is entirely reasonable to expect money-handing programs to do it -- there is simply no excuse not to. Otherwise we end on a slippery slope where little errors are expected because of rounding, and true bugs would not ever be caught before they became large, damaging, bugs.

  • AshG (unregistered) in reply to Henning Makholm
    Henning Makholm:
    AshG:
    Now, speaking of billion-dollar transactions. 3 digits of precision. 1000 transactions, 12-digits each, and you are short 1 dollar.

    Once again, Holy crap!

    Holy crap indeed. Even after 10 transitions you'll be an entire cent off. And that one cent could cost you tens of thousands of dollars.

    Have you ever worked with accountants or auditors? Those people will not yield until the missing penny has been accounted for, on the very reasonable theory that if the system forgets pennies for no known reason, the reason should be found before one day the same bug will lead to a million going missing.

    Doing exact arithmetic on integral numbers of cents is not difficult and therefore it is entirely reasonable to expect money-handing programs to do it -- there is simply no excuse not to. Otherwise we end on a slippery slope where little errors are expected because of rounding, and true bugs would not ever be caught before they became large, damaging, bugs.

    You mean, after 10 multi-million dollar transactions you'll miss a penny? Those transactions don't even include pennies!

    What about IRS 1040? They always want you to round up your tiny income numbers to the closest dollar amounts. These IRS folks must be nuts!

  • Just some guy, you know? (unregistered)

    Unless absolutely necessary I have a policy of not pointing out bugs on web pages anymore: my credit union has a link to an external site that displays the locations of reciprocal service centers - credit unions that operate under different names but are willing to provide notary services, cashiers' checks, check cashing services and so on to members of credit unions in that network. When on the external site an error message comes up saying something about a key being incorrectly configured. I sent a brief FYI to the contact email address and the girl responded by picking a fight with me telling me that I needed to speak with my credit union even though the problem was on her company's site. I asked her for the username/password so the admin at my credit union could log in and fix the error but she didn't grasp the notion and just told me to talk to my credit union again. I asked her why she was unwilling to tell her IT department that was an issue with their web page and again she told me that even though I was using their website to look up addresses the problem had to be with my credit union's webpage.

  • Henning Makholm (unregistered) in reply to AshG

    [quote user="AshG"]Have you ever worked with accountants or auditors? Those people will not yield until the missing penny has been accounted for, on the very reasonable theory that if the system forgets pennies for no known reason, the reason should be found before one day the same bug will lead to a million going missing.

    Doing exact arithmetic on integral numbers of cents is not difficult and therefore it is entirely reasonable to expect money-handing programs to do it -- there is simply no excuse not to. Otherwise we end on a slippery slope where little errors are expected because of rounding, and true bugs would not ever be caught before they became large, damaging, bugs.[/quote]You mean, after 10 multi-million dollar transactions you'll miss a penny? [/quote]

    I refer you to the explanation you quoted but apparently did not read. A missing penny is a sign of an error somewhere in your accounting practices. Such errors must be tracked down and fixed, or you will not be able to file your yearly operating report. Having an army of accountants and auditors try to track down that error costs considerably more than the penny.

    Stop fixating on the monetary size of the discrepancy itself and accept the fact of the world that no errors are allowed in accounting, and ANY error will cost you whatever it takes to fix it.

  • AshG (unregistered) in reply to Henning Makholm
    Henning Makholm:
    I refer you to the explanation you quoted but apparently did not read. A missing penny is a sign of an error somewhere in your accounting practices. Such errors must be tracked down and fixed, or you will not be able to file your yearly operating report. Having an army of accountants and auditors try to track down that error costs considerably more than the penny.

    Stop fixating on the monetary size of the discrepancy itself and accept the fact of the world that no errors are allowed in accounting, and ANY error will cost you whatever it takes to fix it.

    At the end of the tax year:

    Income: $3,652,654,985,652.01 Expenses: $3,652,654,985,652.00

    Auditor: Hmm, where's the extra penny coming from? CFO: Developer, fix it! Developer: Hmm... Update BalanceSheet set Expenses = Espenses + $.01; Commit; Everyone: Standing ovation, cheers, champagne.

  • Joe (unregistered) in reply to pitchingchris

    Dude, it's += '0' NOT += 0

    tricky tricky!

  • Anonymousse (unregistered) in reply to BluePlateSpecial
    BluePlateSpecial:
    I personally have never had a problem with its handling of floating point numbers.

    Maybe you weren't looking hard enough, or not looking at all. After all, $45843.58 looks very much like $45843.59. Or if your test framework is written just as sloppily and also using floating-point numbers, it'll happily make the same mistake...

  • (cs) in reply to AshG
    At the end of the tax year:

    Income: $3,652,654,985,652.01 Expenses: $3,652,654,985,652.00

    Auditor: Hmm, where's the extra penny coming from? CFO: Developer, fix it! Developer: Hmm... Update BalanceSheet set Expenses = Espenses + $.01; Commit; Everyone: Standing ovation, cheers, champagne.

    That sounds very dodgy. Especially if that += $0.01 pushes the expenses to $3,652,654,985,652.02 (or leaves it unchanged because it's past the end of precision) due to the nature of floating-point and rounding. And the auditor will be "what's this transaction?!? There's no details so it must be something illegal".

    (IANAA)

  • Henning Makholm (unregistered) in reply to AshG
    AshG:
    Auditor: Hmm, where's the extra penny coming from? CFO: Developer, fix it! Developer: Hmm... Update BalanceSheet set Expenses = Espenses + $.01; Commit; Everyone: Standing ovation, cheers, champagne.
    Apparently you never met an auditor, or even sat next to one on the bus.

    I will cease my foolish attempt to educate you.

  • AndyC (unregistered) in reply to AshG
    AshG:
    So you are saying your hand-crafted floating point math has better precision than that of the CPU. Let's see.

    Double data type offers you 15 digits. For the majority of money transactions such as purchases (100 bucks or less) this gives you 12 digits of precision, make it 11 since the last digit is always screwed up. It will take your system 10E11 transactions to make a 1 penny mistake.

    Now, speaking of billion-dollar transactions. 3 digits of precision. 1000 transactions, 12-digits each, and you are short 1 dollar.

    Once again, Holy crap!

    Nope, you still don't get it. A double does not give you 15 digits of accuracy. A floating point number cannot even accurately represent 0.1. Ever. Even if you assign a billion bits to store it in. So you are potentially 10 cts off without even performing a single operation. And it starts adding up very quickly.

    Floating point and money just doesn't work. That's why arbitrary precision arithmetic exists. If you're doing maths on money with floating point, you have major issues.

  • foxyshadis (unregistered)

    Wow, you guys are young! Apparently no one remembers the bad old days when the myth that javascript couldn't to arithmetic got started by html writers who didn't know what they were doing. Even I fell for it for a few weeks, before I figured out how utterly wrong it was. Back then, they would do all arithmetic by eval()ing expressions or adding strings like this, obviously the programmer of this monstrosity believed some ancient sample code and never bothered to test whether plain addition worked. I figured at least one person would remember this very persistent myth.

  • Drak (unregistered) in reply to foxyshadis
    foxyshadis:
    Wow, you guys are young! Apparently no one remembers the bad old days when the myth that javascript couldn't to arithmetic got started by html writers who didn't know what they were doing. Even I fell for it for a few weeks, before I figured out how utterly wrong it was. Back then, they would do all arithmetic by eval()ing expressions or adding strings like this, obviously the programmer of this monstrosity believed some ancient sample code and never bothered to test whether plain addition worked. I figured at least one person would remember this very persistent myth.

    Try this in your favourite browser's top bar:

    javascript:alert(8.7 - 4.5);

    Mine (firefox 3.5) doesn't say 4.2

  • (cs) in reply to Drak
    Drak:
    foxyshadis:
    Wow, you guys are young! Apparently no one remembers the bad old days when the myth that javascript couldn't to arithmetic got started by html writers who didn't know what they were doing. Even I fell for it for a few weeks, before I figured out how utterly wrong it was. Back then, they would do all arithmetic by eval()ing expressions or adding strings like this, obviously the programmer of this monstrosity believed some ancient sample code and never bothered to test whether plain addition worked. I figured at least one person would remember this very persistent myth.

    Try this in your favourite browser's top bar:

    javascript:alert(8.7 - 4.5);

    Mine (firefox 3.5) doesn't say 4.2

    Python 2.6 (r26:66714, Feb 3 2009, 20:52:03)
    [GCC 4.3.2 [gcc-4_3-branch revision 141291]] on linux2
    Type "help", "copyright", "credits" or "license" for more information.

    8.7-4.5 4.1999999999999993

    OMG!! Python can't do arithmetic!oneeleven!!

Leave a comment on “Late Payment Math”

Log In or post as a guest

Replying to comment #:

« Return to Article