6 ms·

Why would you say it's an error to use a float for currency? I would imagine it's better to use a float for calculations then round when you need to report a va

• mdellavo 5y ago
  https://stackoverflow.com/questions/3730019/why-not-use-double-or-float-to-represent-currency https://stackoverflow.com/questions/3730019/why-not-use-doub...
• RobLach 5y ago
  Standard practice is to use a signed decimal number with an appropriate precision that you scale around.
• Tainnor 5y ago
  It is widely accepted that using floats for money[1] is wrong because floating point numbers cannot guarantee precision. The fact that you ask is a very good case in point though: Many programmers are not aware of this issue and would maybe not question the "wisdom" of the AI code generator. In that sense, it could have a similar effect to blindly copy-pasted answers from SO, just with even less friction. [1] Exceptions may apply to e.g. finance mathematics where you need to work with statistics and you're not going to expect exact results anyway.
• shishy 5y ago
  micro-dollars are a better way of representing it (multiply by 10e6); store as bigint. See: https://stackoverflow.com/a/51238749 https://stackoverflow.com/a/51238749
  • IncRnd 5y ago
    No, they aren't. Micro-dollars do not exist, so this method is guaranteed to cause errors.
    • mdellavo 5y ago
      this is a common approach when you are dealing in rates less than .01 -- you just need to be sure you are rounding correctly
      • IncRnd 5y ago
        When you are approximating fixed-point using floating-point there is a lot more you need to do correctly other than roun ding. Your representation must have enough precision and range for the beginning inputs, intermediate results, and final results. You must be able to represent all expected numbers. And on. There is a lot more involved than what you mentioned. Of course, if you are willing to get incorrect results, such as in play money, this may be okay.
        • 10000truths 5y ago
          When did mdellavo anything about floating point? You can, and should, use plain old fixed-point arithmetic for currency. That’s what he means by “microdollar”.
        • cjaybo 5y ago
          > store as bigint
          • IncRnd 5y ago
            Thank you. I made a mistake due to the starting comment in the thread.
  • kyrra 5y ago
    Googler, opinions are my own. Over in payments, we use micros regularly, as documented here: https://developers.google.com/standard-payments/reference/glossary#micros https://developers.google.com/standard-payments/reference/gl... GCP on there other hand has standardized on unit + nano. They use this for money and time. So unit would 1 second or 1 dollar, then the nano field allows more precision. You can see an example here with the unitPrice field: https://cloud.google.com/billing/v1/how-tos/catalog-api#getting_the_list_of_skus_for_a_service https://cloud.google.com/billing/v1/how-tos/catalog-api#gett...
• voxic11 5y ago
  Standard floats cannot represent very common numbers such as 0.1 exactly so they are generally disfavored for financial calculations where an approximated result is often unacceptable. > For example, the non-representability of 0.1 and 0.01 (in binary) means that the result of attempting to square 0.1 is neither 0.01 nor the representable number closest to it. https://en.wikipedia.org/wiki/Floating-point_arithmetic#Accuracy_problems https://en.wikipedia.org/wiki/Floating-point_arithmetic#Accu...
• chongli 5y ago
  Using float for currency calculations is how you accumulate a bunch of rounding errors. Standard practice when dealing with money is to use an arbitrary-precision numerical type.
• wiz21c 5y ago
  Using float is perfectly OK since using fixed point decimal (or whatever "exact" math operations) will lead to rounding error anyway (what about multiplying a monthly salary by 16/31 (half a month) ?) The problem with float is that many people don't understand how they work to handle rounding errors correctly. Now there are some cases where float don't cut it. And big ones. For example, summing a set of numbers (with decimal parts) will usually be screwed if you don't round it. And not many people expect to round the results of additions because they are "simple" operations. So you get errors in the end. (I have written applications that handle billions of euros with floats and have found just as many rounding errors there as in any COBOL application)
  • mdellavo 5y ago
    It seems incorrect to determine a half a month as 16/31 but ok , for your proposed example: >>> from decimal import Decimal >>> Decimal(1000) * Decimal(16) / Decimal(31) Decimal('516.1290322580645161290322581') >>> 1000 * 16 / 31 516.1290322580645 The point is using Decimal allows control over precision and rounding rather than accepting ad-hoc approximations of a float. https://docs.python.org/3/library/decimal.html https://docs.python.org/3/library/decimal.html If it were me, I wouldn't go around bragging about how much money my software manages while being willfully ignorant of the fundamentals.
    • wiz21c 5y ago
      OK, the salary example was a bit simplified; in my case it was about giving financial help to someone. That help is based on a monthly allowance and then split in the number of allocated days in the month, that's for the 16/31. Now for your example, I see that float and decimal just give the same result. Provided I'm doing financial computations of a final number, I'm ok with 2 decimals. And both your computations work fine. Th decimal module in python gives you number of significant digits, not number of decimals. You'll end up using .quantize() to get to two decimals which is rounding (so, no advantage over floats). As I said, as soon as you have division/multiplication you'll have to take care of rounding manually. But for addition/subtraction, then decimal doesn't need rounding (which is better). The fact is that everybody say "floats are bad" because rounding is tricky. But rounding is always possible. And my point is that rounding is tricky even with the decimal module. And about bragging, I can tell you one more thing : rounding errors were absolutely not the worse of our problems. The worse problem is to be able to explain to the accountant that your computation is right. That's the hard part 'cos some computations imply hundreds of business decisions. When you end up on a rounding error, you're actually happy 'cos it's easy to understand, explain and fix. And don't start me on how laws (yes, the texts) sometimes explain how rounding rules should work.
• joquarky 5y ago
  You don't want to kick the can down to the floating point standard. Design for deterministic behavior. Find the edge cases, go over it with others and explicitly address the edge case issues so that they always behave as expected.
• IncRnd 5y ago
  By definition, currency uses fixed point arithmetic not floating point arithmetic.
  • bidirectional 5y ago
    Not even remotely true. It is entirely context dependent. I've always used floats when working in finance.
    • IncRnd 5y ago
      Some people say "goin der" instead of "going there", that doesn't change the definitions of words, just because people are lazy with their language.
      • ExtraE 5y ago
        Your point in the floating-point discussion is true, but you’re wrong about this one- linguistics is a descriptive field, not a prescriptive one.
      • bidirectional 5y ago
        I fail to see your point. Floats are best practice for many financial applications, where model error already eclipses floating point error and performance matters.
• ConceptJunkie 5y ago
  Because it's an error to use floats in almost every situation. And currency is something where you don't want rounding errors, period. The more I've learned about floating point numbers over the years, the less I want to use them. Floats solve a specific problem, and they're a reasonable trade-off for that kind of problem, but the problem they solve is fairly narrow.