Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

0.30000000000000004

0.30000000000000004.com

Post reply on HN
Print view View original

291–300 of 422 posts

Re: 0.30000000000000004

#291

Post by piadodjanho »

ezrast wrote: post #268
piadodjanho wrote: post #245

Earlier quoted context omitted.

I think the "floating point are bad for storing currencies" is one of the most common misconception about floating point. Most people don't realize that the IEEE-754 single precision floating point represent real numbers with 9 decimal digits (or 23 binary digits). The double, on the other hand, represents the real numbers with 17 decimal digits. This means that the double error UPPER BOUND is (0.00000000000000001)/2…

World GDP is around 87 trillion dollars. $ ruby -e 'pp 87e12 + 0.01' 87000000000000.02 If you're certain that your software will never handle national-economy-scale or hyperinflationary use cases, then sure, you may be able to get away with 64-bit floats, but I think "no need to worry" is overstating your case. Please do worry about precision until you've proven you don't need to.

Yeah, I should had be more careful with my words.

For the vast majority of person, there is no need to worry so much about using fp to represent currencies. There are other issues with float that will bite you in your back before precision became one of them.

Re: 0.30000000000000004

#292

Post by tzs »

piadodjanho wrote: post #278
tzs wrote: post #231

Earlier quoted context omitted.

> Performing arithmetic operations against money in floating point is the dangerous part, as error can accumulate beyond an atomic unit. A good example of this is trying to compute the sales tax on $21.15 given a tax rate of 10%. The exact answer would be $2.115, which should round to $2.12. IEEE 64-bit floating point gives 2.1149999999999998, which is hard to get to round to 2.12 without breaking a bunch of other ca…

> IEEE 64-bit floating point gives 2.1149999999999998, which is hard to get to round to 2.12 without breaking a bunch of other cases. Your issue is on how to print the float, not with the precision of fp. For instance, `21.15 * 0.1` can be print both as 2.115 or 1.12 depending on how many decimal digits of precision you set your print function. I manage to get those results with printf using `%.3f` and `%.2f`, respec…

> Your issue is on how to print the float, not with the precision of fp. For instance, `21.15 * 0.1` can be print both as 2.115 or 1.12 depending on how many decimal digits of precision you set your print function. I manage to get those results with printf using `%.3f` and `%.2f`, respectively.

I get 2.115 with %.3f and 2.11 with %.2f. Here's my test program. Same result on my Mac with clang and my Debian 8 server with gcc.

  #include 
  
  double tax_on(double amt, double rate);
  
  int main(void)
  {
      double amt = 21.15;
      double rate = 0.1;
      double tax = tax_on(amt, rate);
      printf("%.3f\n", tax);
      printf("%.2f\n", tax);
      return 0;
  }
  
  double tax_on(double amt, double rate)
  {
      return amt * rate;
  }

Re: 0.30000000000000004

#293

Post by [deleted] »

recursive wrote: post #206
larrik wrote: post #91

Earlier quoted context omitted.

This is false. It's not correct to handle currency with floating point types.

I don't see any problem with it if it's decimal. Here's an accepted answer on stack overflow with hundreds of upvotes recommending the use of `decimal` to store currency amounts in C#. That's a decimal floating point type. https://stackoverflow.com/a/693376/44743

[deleted]

Re: 0.30000000000000004

#294

Post by piadodjanho »

zAy0LfpBZLC8mAC wrote: post #282
piadodjanho wrote: post #245

Earlier quoted context omitted.

I think the "floating point are bad for storing currencies" is one of the most common misconception about floating point. Most people don't realize that the IEEE-754 single precision floating point represent real numbers with 9 decimal digits (or 23 binary digits). The double, on the other hand, represents the real numbers with 17 decimal digits. This means that the double error UPPER BOUND is (0.00000000000000001)/2…

> Most people don't realize that the IEEE-754 single precision floating point represent real numbers with 9 decimal digits (or 23 binary digits). The double, on the other hand, represents the real numbers with 17 decimal digits. No, they don't. They merely can be converted back to decimal with those numbers of significant digits without loss of information. That is important because (a) if this matters, you have to m…

In a previous discussion, someone was worrying about using floats to represent price in JS. I think this is a consequence on the fear mongering on using floats to store currencies.

Floating Points are hard. There is a study done with academics that shows that even researches that works with float point everyday forget about the format intricacies. And the study didn't even look into the compiler mess.

But I agree with you, some (a lot?) of caution is needed when working with float point is good.

Re: 0.30000000000000004

#295

Post by kazinator »

tzs wrote: post #292
piadodjanho wrote: post #278

Earlier quoted context omitted.

> IEEE 64-bit floating point gives 2.1149999999999998, which is hard to get to round to 2.12 without breaking a bunch of other cases. Your issue is on how to print the float, not with the precision of fp. For instance, `21.15 * 0.1` can be print both as 2.115 or 1.12 depending on how many decimal digits of precision you set your print function. I manage to get those results with printf using `%.3f` and `%.2f`, respec…

> Your issue is on how to print the float, not with the precision of fp. For instance, `21.15 * 0.1` can be print both as 2.115 or 1.12 depending on how many decimal digits of precision you set your print function. I manage to get those results with printf using `%.3f` and `%.2f`, respectively. I get 2.115 with %.3f and 2.11 with %.2f. Here's my test program. Same result on my Mac with clang and my Debian 8 server wi…

The thing is that if 2.115 represents a calculated dollar figure, such as the value of some transaction or the cost of something or whatever, then we should round it to 2.12. (Unless we are working in a financial domain that deals with fractions of a cent.) Now in floating-point, we don't exactly have the exact value 2.12, but we have something that is extremely close. So close that if we happen to print it to %.3f, we better get 2.120, and if we print it to %.4f, we better see 2.1200.

That some monetary calculation works out to $2.115 (and is left that way) instead of being correctly rounded $2.12 doesn't add up to a valid argument against using floating-point for money.

I think piadodjanho does have a point there in the grandparent comment; "don't use floating-point for money" may just be a repeated mantra that doesn't entirely hold water. If extremely accurate engineering and scientific calculations can be done with floating-point, surely we can get floating-point values to measure stacks of pennies with the proper care in the programming.

Re: 0.30000000000000004

#296

Post by mynegation »

chrisseaton wrote: post #290
lmilcin wrote: post #277

Earlier quoted context omitted.

I develop accounting software for banks, brokerage houses and likes. Currency, taxes, rebates, etc. handling is NEVER done with floating point. Whatever you do with money you need predictable, reproducible results. It is norm that calculations are checked by software at two companies on both sides of transaction. Any discrepancies are alarms, bug reports, unhappy customers. Every significant operation is exactly spec…

> Currency, taxes, rebates, etc. handling is NEVER done with floating point. Nonsense. I’ve seen real banking code at reputable banks that uses floats. > Whatever you do with money you need predictable, reproducible results. Floats aren’t random. They’re perfectly deterministic, predictable and reproducible. If you do the same operation in two places you get the same result.

I write real banking code. There is definitely a banking code that uses floats, e.g. valuation of financial instruments. The parent comment talks about software that does transactions and “simpler” calculations, like taxes and fees etc.

When people talk about non-determinism of floating point, what they usually mean is non-associativity, that is (x+y)+z may not be exactly equal to x+(y+z).

Re: 0.30000000000000004

#297

Post by kccqzy »

_y5hn wrote: post #67
_bxg1 wrote: post #17

I remember in college when we learned about this and I had the thought, "Why don't we just store the numerator and denominator?", and threw together a little C++ class complete with (then novel, to me) operator-overloads, which implemented the concept. I felt very proud of myself. Then years later I learned that it's a thing people actually use: https://en.wikipedia.org/wiki/Rational_data_type

It's actually in use in many places, for things like handling currency and money, and for when you get funny corner cases involving rounding such numbers and pooling the change. Whenever I see someone handling currency in floats, something inside me wither and die a small death.

> Whenever I see someone handling currency in floats, something inside me wither and die a small death.

Meh. When used correctly in the right circumstances it is acceptable to use floats.

Here's an example. Suppose you are pricing bonds, annuities, or derivatives. All the intermediate calculations make essential use of floating point operation. The Black–Scholes model for example requires the logarithm, the exponential, the square root, and the CDF of the normal distribution. None of that is doable without floats.

Even for simpler examples it is sometimes okay to use floats. If you only ever need to store an exact number of cents, you can totally store the number of cents in a double. Integer operations are exact using IEEE-754 double operations when they are smaller than 2^53-1 or so. There's usually no benefit of doing so, but hey it's possible.

Re: 0.30000000000000004

#298

Post by throwawaymath »

mynegation wrote: post #296
chrisseaton wrote: post #290

Earlier quoted context omitted.

> Currency, taxes, rebates, etc. handling is NEVER done with floating point. Nonsense. I’ve seen real banking code at reputable banks that uses floats. > Whatever you do with money you need predictable, reproducible results. Floats aren’t random. They’re perfectly deterministic, predictable and reproducible. If you do the same operation in two places you get the same result.

I write real banking code. There is definitely a banking code that uses floats, e.g. valuation of financial instruments. The parent comment talks about software that does transactions and “simpler” calculations, like taxes and fees etc. When people talk about non-determinism of floating point, what they usually mean is non-associativity, that is (x+y)+z may not be exactly equal to x+(y+z).

> When people talk about non-determinism of floating point, what they usually mean is non-associativity, that is (x+y)+z may not be exactly equal to x+(y+z).

Good example of this, in Python 3:

    >>> (0.1 + 0.2) + 0.3
    0.6000000000000001
    >>> 0.1 + (0.2 + 0.3)
    0.6

Re: 0.30000000000000004

#299

Post by erikwiffin »

GuB-42 wrote: post #111

That's one of the worst domain name ever. When the topic comes along, I always remember about "that single-serving website with a domain name that looks like a number" and then take a surprisingly long time searching for it. I have written a test framework and I am quite familiar with these problems, and comparing floating point numbers is a PITA. I had users complaining that 0.3 is not 0.3. The code managing these c…

It may be the worst domain name ever, but the site only exists because I thought that using "0" as a subdomain was a neat trick, and worked back from there to figure out what to do with it.

FWIW - the only way I can ever find my own website is by searching for it in my github repositories. So I definitely agree, it's not a terribly memorable domain.

Re: 0.30000000000000004

#300

Post by Waterluvian »

The thing that surprised me the most (because I never learned any of this in school) was not just the lack of precision to represent some numbers, but that precision falls off a cliff for very large numbers.
Post reply on HN