• Yazeran (unregistered)

    Actually, I'm impressed that it has been working good enough that it went into production at all.

    It is (or more likely should be) common knowledge that when dealing with money in a program you can only do it in integers (or a specific currency type)...

    But again common sense is not so common as it ought to be....

    Yazeran

  • Sauron (unregistered)

    It's like a salami-slicing attack, but it's just bad code.

  • Charles (unregistered)

    Also cf Office Space.

  • Michael R (unregistered)

    Good old float/doubles for monetary values == job security!

  • (nodebb)

    Sadly software is still biased towards being self-taught and ignorant of history. Fixed point decimal arithmetic has been a hardware feature for at least 60 years.

  • (nodebb)

    Delphi? So this code has been in production for... 20+ years? Is that possible?

  • Yazeran (unregistered) in reply to bradwood

    Sure it is.

    Banks still have Fortran programs running on mainframes dating back to the 70's or 80's In most cases the programs are now running on modern hardware with a suitable emulator to simulate an IBM360 series mainframe....

    Yazeran

  • LZ79LRU (unregistered) in reply to bradwood

    There is still new software being written in Delphi today.

    Just something to keep you awake at night.

  • (nodebb)

    What about the additional WTFery of returning 0.00 if there's any exception?

    I still can't figure out what the dAdditionalAmount thing is about. Is it trying to prevent banker's rounding of xxx.50 values?

  • (nodebb) in reply to bradwood

    Delphi is still used today and has modern compilers and tooling even for mobile development, Linux and MacOS.

  • carl witthoft (unregistered) in reply to Yazeran

    Well, no, you cannot easily use integer values for your currency, because it's very easy for a vendor to have a per-part price with lots of decimal digits. The system has to accommodate, e.g., the per-unit price of a M4-1.25 screw of $ 0.012225 . Yes, the final price paid is (probably) going to stop with an integer number of cents, but not the source. And then there's the problem of multiplying the sale price by 6.023% to add sales tax or something.

  • (nodebb)

    Well, no, you cannot easily use integer values for your currency, because it's very easy for a vendor to have a per-part price with lots of decimal digits. The system has to accommodate, e.g., the per-unit price of a M4-1.25 screw of $ 0.012225 . Yes, the final price paid is (probably) going to stop with an integer number of cents, but not the source. And then there's the problem of multiplying the sale price by 6.023% to add sales tax or something.

  • Brian Boorman (unregistered)
    They shift the number one ten-thousandth of a cent away from zero

    Shouldn't that be "one ten-thousandth of a dollar"? I.e. one-hundredth of a cent?

  • TheCPUWizard (unregistered)

    "Well, no, you cannot easily use integer value" -- sure you can.... an integer mantissa and an integer "power of 10" (not power of 2) exponent... Or an rational number where both numerator and denominator are integer.....

  • (nodebb) in reply to Barry Margolin

    I noticed that bit of fun in the exception handler too. "Problem with our software? Guess what, you now have $0.00!"

  • (nodebb)

    The additional bit is probably to handle cases where a value like 1.494999998 should be rounded to 1.50.

  • (nodebb)

    I always used integers. My code predated the Currency type and I explicitly didn't want fractional cents to exist anyway. It was more important that every calculation appear correct than truly be correct. Fractional pennies had to be destroyed the instant they arose. (The basic problem is that normally there was a very short summary page, but there was also a high detail page that explained how it arrived at the numbers on the summary page--and there were some percentages involved. If a fractional penny could be created by a percentage it wouldn't show up on a high detail so it couldn't show up on the summary. 10/3+10/3+10/3 needed to equal 9 because it had to match.)

  • Paul M (unregistered)

    Delphi, very reasonably, does banker's rounding, where exact 0.5 values are rounded to the nearest even integer. Maybe this code is an attempt to circumvent this?

  • Bat Conley (unregistered)

    He forgot the code to handle rounding errors by transferring the fractional cents to his personal bank account?

  • MaxiTB (unregistered) in reply to Paul M

    -.5 and fixed ;-)

  • Scott (unregistered)

    Maybe they're trying to steal all those fractional cents like in Superman II?

  • Gnasher729 (unregistered)

    I would have thought that quite often there are legal rules that you have to follow, that tell you exactly what the result of any calculation should be. And then you implement it any way you like, as long as you get the correct result.

    For example, in the Uk if I buy 20 items for £1.19 each, the seller has the choice of calculating VAT on £23.80 = £4.76, or calculating VAT on £1.19 = 24p and charging that 20 times = £4.80. The calculation is done according to the rules of the tax office.

Leave a comment on “Rounding Currency”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article