• (nodebb)

    This must be some kind of superstition. Many people believe that "money loves being recounted". Perhaps these programmers thought that "prices like being re-parsed".

  • Prime Mover (unregistered)

    So let me guess: TRWTF here is being unable to spell "separators"?

  • Prime Mover (unregistered)

    Had a back end interface once which I was reading the data out of, where the developer responsible was adamant that he was doing the right thing by sending the data already formatted.

  • Dave (unregistered)

    Dealing with things like lists of prices from multiple tyre suppliers, it wouldn't surprise me if the data is in wildly inconsistent formats, let alone varying in whether it has thousands separators. I've received price data from a single car parts supplier which wasn't consistently formatted.

  • Tim (unregistered) in reply to Mr. TA

    sources for this?

    https://www.google.com/search?q=%22money+loves+being+recounted%22

    ==> No results found for "money loves being recounted".

  • Ruud van der Graaff (unregistered)

    Priceless............

  • COB (unregistered)

    I deal with this issue on a monthly basis, developers that for one reason or another want to store dollar amounts AND dates as string values.

  • anon (unregistered)

    I happen to know the reason for this. Russell seems to have taken over my position in the tire warranty business.

    It's because the consultants this company retains are complete idiots, Dave in particular.

  • (nodebb)

    If it's worth converting once, it's certainly worth converting twice. Or thrice. What confuses me after 20+ years of software development, is that every time it's converted, it is converted into the same format! How unlikely is that?

  • ooOOooGa (unregistered)

    I inherited a UI dealing with price plans for services. About 25 different price values to be entered on one page. Each of them had the dollars and cents as separate text input fields.

    I can only assume it was done that way to accommodate the same type of people who are unable to put a period at the end of a sentence.

  • ZZartin (unregistered)

    /shrug this seems like a really cludgy way to force it to 2 decimal places.

  • (nodebb) in reply to ooOOooGa

    About 25 different price values to be entered on one page. Each of them had the dollars and cents as separate text input fields.

    I hope you converted those to all use number spinners where you can only change values by one each click.

  • (nodebb) in reply to Tim

    It's a literal translation of a Russian proven which sounds funny in English. A similar English language proverb is "a penny saved is a penny earned".

  • (nodebb)

    Storing prices as strings or as separate dollar and cent integers makes it less likely that your site will appear on an Error'd post due to in-exact representation turning into excessive precision.

  • Heinebold (unregistered) in reply to sibtrag

    Why would you need separate dollar and cent integers? Just store the price in cents then.

    Btw, if you do calculations that need better precision than cents, that is still no reason for floats. Use integers of a unit fitting the required precision, like "Millidollars" or whatever.

  • Bill Turner (google)

    At least they're using decimal rather than float/double. That would just add to the WTF-iness of it all.

  • Loren Pechtel (unregistered)

    I think this is a defense against other sloppy programmers not getting the formatting right, or getting foreign formatting. It's not done too well, though.

  • (nodebb)

    Just store the price in cents then.

    That's what fixed point math does. It's great for some things (and more efficient than floating point) but terrible for others.

    A good rule of thumb is that if you're mostly adding/subtracting values, or are only multiplying by integers, fixed point can work well (unless you go out of range). If you're multiplying (or dividing) two non-integer values together, you get far fewer surprises if you use floating point.

  • This one hurts *me* (unregistered)

    It's staggering how many costly conversions there are.

  • (nodebb)

    My first issue with this is the variable naming. Why decTotalPriceF? Why not DecimalTotalPriceFrontTires. It's not 1984 with a 10" crt screen.

  • (nodebb) in reply to Heinebold

    The main problem with using floating-point numbers for money is that you lose your least significant digits when you get to really large values. Entries in the General Ledger need to be precise to the cent (or so, depending on jurisdiction) and you can't afford to round off all but the six most significant digits of a value. Even Double floating point only keep 15 digits of precision. This is part of the reason for the Decimal type in C#, which can handle 23 digits of precision without throwing away any digits in the process.

  • ooOOooGa (unregistered) in reply to dkf

    I hope you converted those to all use number spinners where you can only change values by one each click.

    Sorry, no.

    Though when I was in college and working for the IT department there, I had someone complain that the panel on the overhead projector controls didn't always have the button that they wanted showing on the LCD UI. I offered to have just one button that would change its label every second or so. Then they can just wait for the one they want to come by and click it.

    They weren't overly impressed with that idea.

  • (nodebb)

    I think the code was written by multiple unrelated parties, and most of them never read what each other wrote.

  • Erwin (unregistered) in reply to Mr. TA

    The Dutch have a proverb suggesting that you will lose your money if you count it too often: "Counted sheep leave the pen", so the opposite of "money loves being recounted".

  • Officer Johnny Holzkopf (unregistered) in reply to This one hurts *me*

    There are FOUR conversion! To be exact, it might be 4 5 ± 12,7.6⅝ conversions, depending on what interested party you ask...

  • RLB (unregistered) in reply to Nutster

    The main problem with using floating-point numbers for money is that you lose your least significant digits when you get to really large values.

    Well, that's a problem, but the main problem (or at least the only one I've ever encountered in practice) is that it is very hard to ensure there are guaranteed no rounding errors, never, at all, and that when there are, the beancounters will get mad at you, and rightly so.

  • (nodebb) in reply to Erwin

    That is hilarious. Sheep are different than money obviously, but still definitely a difference between national belief systems.

  • Verily, y'all (unregistered) in reply to Erwin

    Let us also remember the Parable of the Talents from the Book of Matthew... and also the Kenny Rogers song "The Gambler"

  • Andy Miller (unregistered)

    Surely the back tyres should be handled by the back-end system, and the front tyres by the front-end system?

  • (nodebb) in reply to Andy Miller

    Surely the back tyres should be handled by the back-end system, and the front tyres by the front-end system?

    LOL

  • (nodebb)

    Since this is web-based, the real fun will start when some calculations are done with the numbers parsed from the strings on the client side, and the client uses different number formatiing than the server. Welcome to the daily what the fun!

  • (nodebb) in reply to ooOOooGa

    I inherited a UI dealing with price plans for services. About 25 different price values to be entered on one page. Each of them had the dollars and cents as separate text input fields. I can only assume it was done that way to accommodate the same type of people who are unable to put a period at the end of a sentence.

    I wonder though what the best solution would be. If it is a text field, you WILL get people typing 10,000 with one user meaning 10000.00 and another meaning 10.00. But likewise you'll get users inserting just that i to the dollar field I guess.

    The nicest solution would likely be a currency input field, that enforces that the number is always shown in a format with two decimals, regardless of what the user has typed, so at least. the DISPLAY after input is clear on the format. (and 10,00 cannot easily be misread as 1000).

    Of course that breaks down when you get into the weird edge cases where currency has a third decimal.

  • RLB (unregistered) in reply to R3D3

    Of course that breaks down when you get into the weird edge cases where currency has a third decimal.

    And don't think about supporting India with their lakhs and crores.

  • Frans Lytzen (unregistered)

    I think I may know the original reason for at least some of this... You see, decimal in C# remembers how many decimals it has seen. decimal x = 0m; X.ToString() => "0" X = X + 0.00m; X.ToString() => "0.00".

    If you Google how to show a decimal with two decimals, some suggestions use that exact parse of a string to get to that state. This is useful when serialising rather than directly calling ToString (though adding 0.00m and calling Round is obviously better in that case). Obviously unnecessary when you can use "N2" in this case.

    I suspect this code started out using that approach to show decimals and gradually got changed by someone who also didn't fully understand this.

Leave a comment on “Price Conversions”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article