• tiny clanger (unregistered) in reply to Gene Wirchenko

    No, if you're using Java, as this example is, then the answer is just DON'T.

    BigDecimal does everything you need, including numerous rounding options, one of which will be legally required for financial transactions, depending where you are in the world (e.g in Europe halves are rounded up when needed, but I believe the USA rounds down).

    I've seen numerous applications where this wasn't done, and watched with amusement as customers of (and subsequently management within) reputable finance industry companies went crazy as they started seeing 999.99 instead of 1000 and questions of trustworthiness got raised.

    However it's usually fairly quick to fix once you've identified where all the floats are in the code, and sent the developer(s) responsible one of the many web articles on why you MUST use BigDecimal in Java for this kind of work.

  • (cs) in reply to ¯\(°_o)/¯ I DUNNO LOL
    ¯\(°_o)/¯ I DUNNO LOL:
    I'm going to add this: if your decimal point is not FLOATING, then don't fucking use FLOATING point numbers. Use fixed point and scale your numbers input/printing or when doing multiplication or division by other fixed-point numbers.

    Example: represent money as an integer number of pennies, not as a floating point number of dollars. ".10" is a repeating fraction in binary, just like 1/3 is in decimal, which is why you don't use floats.

    But sometimes money is "sort of floating", as when you're working with financial amounts that can be in a lot of different currencies but are using the French (aka ISO) standard for representing them.

    Dollars of various sorts (US, Canadian, Australian, Hong Kong, Taiwan) have two decimal places, as do British pounds, Euros, Mexican pesos, Japanese yen (although nobody actually uses sen), etc. Others such as Thai baht, Indian rupees, the now-defunct Italian lira (which were still funct back when I had to deal with this stuff), are un-subdivided, i.e., zero decimal places. A few Middle-Eastern things like Bahraini or Libyan dinar break down into thousandths so you need three decimals.

    I searched long and hard for any place breaking their currency into tenths so I could comprehensively test the logic that allowed from zero to three decimals, but it appears they don't exist. Neither (since the Brits decimalised the pound) does anyone break down their simoleons into other than decimal fractions.

  • foo AKA fooo (unregistered) in reply to ¯\(°_o)/¯ I DUNNO LOL
    ¯\(°_o)/¯ I DUNNO LOL:
    I'm going to add this: if your decimal point is not FLOATING, then don't fucking use FLOATING point numbers. Use fixed point and scale your numbers input/printing or when doing multiplication or division by other fixed-point numbers.

    Example: represent money as an integer number of pennies, not as a floating point number of dollars. ".10" is a repeating fraction in binary, just like 1/3 is in decimal, which is why you don't use floats.

    +100.0e0!

  • Mick O'Hea (unregistered)

    It looks like it's reading/writing a flat file that's an interface to some legacy system that requires the data in that format, e.g. something COBOL based.

  • Norman Diamond (unregistered) in reply to da Doctah
    da Doctah:
    Dollars of various sorts (US, Canadian, Australian, Hong Kong, Taiwan) have two decimal places, as do British pounds, Euros, Mexican pesos, Japanese yen (although nobody actually uses sen), etc. Others such as Thai baht, Indian rupees, the now-defunct Italian lira (which were still funct back when I had to deal with this stuff), are un-subdivided, i.e., zero decimal places. A few Middle-Eastern things like Bahraini or Libyan dinar break down into thousandths so you need three decimals.

    I searched long and hard for any place breaking their currency into tenths so I could comprehensively test the logic that allowed from zero to three decimals, but it appears they don't exist.

    In some places in Hong Kong I saw prices with a single decimal place, though the increment was still referred to as ten-cents not as one-tenth. In mainland China one-tenth is one-tenth and one-hundredth is one-hundredth.

    Historically in Japan there was 1 rin (one-thousandth) and during World War II there was still 5 rin (five one-thousandths). Conscripted soldiers were referred to as issen gorin because postage for a conscription notice was 1 sen 5 rin. Fractions of a yen are no longer legal tender. Sometimes accounting uses them; for example a pharmacy might account for 50 pills at 8.45 yen each and then truncate the total, but a bank passbook doesn't show any fractions.

    I have some Thai coins for 25 satang (25 hundredths of a baht) and Indian coins for some quantities of paises (hundredths of a rupee), though I don't recall seeing fractions in prices.

    By the way, in the other direction, quadrillion is used in measuring Japan's debt.

  • (cs)
  • pangalactic (unregistered) in reply to ¯\(°_o)/¯ I DUNNO LOL

    Or to put it a bit more succinctly: floating point ain't worth a dime.

  • pangalactic (unregistered) in reply to ¯\(°_o)/¯ I DUNNO LOL
    ¯\(°_o)/¯ I DUNNO LOL:
    I'm going to add this: if your decimal point is not FLOATING, then don't fucking use FLOATING point numbers. Use fixed point and scale your numbers input/printing or when doing multiplication or division by other fixed-point numbers.

    Example: represent money as an integer number of pennies, not as a floating point number of dollars. ".10" is a repeating fraction in binary, just like 1/3 is in decimal, which is why you don't use floats.

    Or to put it a bit more succinctly: floating point ain't worth a time.

  • (cs)

    Yeah, it's time to retire the Reply button.

  • np (unregistered) in reply to Raymond
    Raymond:
    ... The assumption that all money amounts are in the form of pennies is easily dis-proven. The "cost" per gallon of gas in the US is typically to the tenth of a penny. Using integers to hold fractions of dollars is problematic at best, and difficult to properly extend in the future to higher precision levels.

    And I have bought stock with an accuracy at a ten-thousandth of a dollar. But I think putting an integer (4-byte, unsigned) for a fraction of a dollar is sufficient for most use-cases. And having it wrapped as a data structure beforehand makes it easier to extend in the future to something with a higher range (8, 16-bytes, dynamic scaling).

    But not trusting double and then using 3 of them seems brillant.

  • (cs) in reply to Paul Neumann
    Paul Neumann:
    Adrian:
    I'll bite. You are female and I have fallen in love.
    While there is at least a small number of participants in any fetish, biting ranks only slightly higher than oculolinctus. I would suggest a different first approach to love.
    I guess the (love) life of a vampire is not an easy one.
  • (cs) in reply to Liam
    Liam:
    Not even BigDecimals, this looks like C#, which has had a native base-10 decimal type since day one.

    Actually it's Java (note the case of String and toString).

    So yes, TRWTF is using double instead of BigDecimal.

  • (cs) in reply to Christian
    Christian:
    Actually it does not matter as java will optimize those string operations and replace them with a stringbuilder anyway. With + you get a nicer looking code and java does the stringBuilder optimization for you anyway.
    You have obviously never looked at decompiled Java code. "Optimise" is a bit of a stretch.
  • ideo (unregistered) in reply to anonymous
    anonymous:
    Paul Neumann:
    Adrian:
    I'll bite. You are female and I have fallen in love.
    While there is at least a small number of participants in any fetish, biting ranks only slightly higher than oculolinctus. I would suggest a different first approach to love.
    Tell that to the chick I screwed at a party - I was literally afraid to let her mouth anywhere near my junk. It was hard enough just trying to extract pieces of my face out from between her jaws.
    I like biting! It's just like kissing, only there's a winner.
  • (cs) in reply to Norman Diamond
    Norman Diamond:
    In some places in Hong Kong I saw prices with a single decimal place, though the increment was still referred to as ten-cents not as one-tenth. In mainland China one-tenth is one-tenth and one-hundredth is one-hundredth.
    My go-to source for Chinese CDs and videos has a distribution center in San Jose, and their pricing in US dollars is organized pretty much the way it ought to be. But for a few albums I couldn't get there, I used to have a second source that operated directly out of Taipei, which quoted prices on their website in US dollars and tenths (a particular CD might be listed as $14.1 or $11.9).

    Never seemed to cause any issues with my credit card companies, but the presentation looked decidedly shady.

  • trololo (unregistered)

    beancounters gone wild... ... beancounters gone programming

    ...quick hide your kids, hide your wife ...

    captcha: nobis (the latin of noob)

  • gnasher729 (unregistered) in reply to chubertdev
    chubertdev:
    That's nice. For people who can't handle these big numbers, the banknote shows what you can buy with it - three stones. Do they have a Big Mac on the five hundred trillion dollar note?
  • Sir Galahad the Pure (unregistered) in reply to gnasher729
    gnasher729:
    chubertdev:
    That's nice. For people who can't handle these big numbers, the banknote shows what you can buy with it - three stones. Do they have a Big Mac on the five hundred trillion dollar note?

    So le BigMac weights, erm costs 15 stone?

  • faoileag (unregistered) in reply to chubertdev
    chubertdev:
    "OK, Google. How many pints are there in a gallon?*"
    Somehow I just envisioned you as the knight guarding the bridge in Monty Python's Holy Grail...

    ..and expected Google to answer: "Do you mean an imperial gallon or a us gallon?"

  • faoileag (unregistered) in reply to Sir Galahad the Pure
    Sir Galahad the Pure:
    gnasher729:
    chubertdev:
    That's nice. For people who can't handle these big numbers, the banknote shows what you can buy with it - three stones. Do they have a Big Mac on the five hundred trillion dollar note?

    So le BigMac weights, erm costs 15 stone?

    After eating a lot of burgers you will end up weighing 15 stone.

    Captcha "transverbero" TRWTF is long captchas. I prefer "nibh"

  • Bob (unregistered) 
    (done this way because we can not represent a decimal number exactly)

    TRWTF is that you still use a floating point data type (double)

  • (cs) in reply to faoileag
    faoileag:
    chubertdev:
    "OK, Google. How many pints are there in a gallon?*"
    Somehow I just envisioned you as the knight guarding the bridge in Monty Python's Holy Grail...

    ..and expected Google to answer: "Do you mean an imperial gallon or a us gallon?"

    That would be determined by the localization/localisation settings of your Google account.

  • Norman Diamond (unregistered) in reply to faoileag
    faoileag:
    chubertdev:
    "OK, Google. How many pints are there in a gallon?*"
    Somehow I just envisioned you as the knight guarding the bridge in Monty Python's Holy Grail...

    ..and expected Google to answer: "Do you mean an imperial gallon or a us gallon?"

    But it doesn't matter! The number of ounces is different, and the number of cups is different, but the number of pints is the same.

    Of course the number of litres is different too, but that's a different difference.

  • Norman Diamond (unregistered) in reply to chubertdev
    chubertdev:
    Oh yeah, how could I forget. Who needs those miniscule quadrillions after all.

    And indeed how could I forget. Reentry cards for foreigners to depart Japan temporarily with intent to return have a box where we have to fill in the amount of money we're carrying. One numeral. One total amount. After that in parentheses is a list, yen, dollars, etc. So I circle the word for yen and the word for dollars and the word for etc., count everything and add them all up, and put the total in the box. No problem. So one time I carried a Zimbabwe one hundred trillion dollar bill along with some US dollars and yen, added everything up, and wrote the total in the box. No problem.

  • Meep (unregistered) in reply to Raymond
    Raymond:
    ... The assumption that all money amounts are in the form of pennies is easily dis-proven. The "cost" per gallon of gas in the US is typically to the tenth of a penny. Using integers to hold fractions of dollars is problematic at best, and difficult to properly extend in the future to higher precision levels.

    When advertising a price per unit you can specify it in whatever precision you please, but the actual exchange of money and thus the amount of money in any given account is never more precise than pennies.

    So you never have a reason to worry about someone else using a more precise value than pennies.

  • Essex Kitten (unregistered)

    Let me guess: they ported it from COBOL.

Leave a comment on “Printing Decimal Numbers is HARD!”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article